harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Zhang" <zhanghuang...@gmail.com>
Subject Re: [classlib][lang] AbstractStringBuilder, abstract class?
Date Sun, 08 Oct 2006 00:49:14 GMT
On 10/8/06, Nathan Beyer <nbeyer@gmail.com> wrote:
>
> I commited a change. The class is now abstract. Please verify that is
> solves the issue.


Thank you Nathan, it works fine now!

Would someone mind posting a JIRA issue with an additional test for
> StringBuffer and StringBuilder.
>
> -Nathan
>
> On 10/7/06, Nathan Beyer <nbeyer@gmail.com> wrote:
> > Seems like it was just a oversight. I can check in a fix.
> > -Nathan
> >
> > On 10/7/06, Alexey Varlamov <alexey.v.varlamov@gmail.com> wrote:
> > > 2006/10/7, Geir Magnusson Jr. <geir@pobox.com>:
> > > > sounds reasonable, but don't go based on my word, of course.
> > > >
> > > > Interesting question is why AbstractStringBuilder isn't abstract...
> > >
> > > It does not really matters from implementation POV, and the name was
> > > just chosen after the RI - sorta be deeply compatible.  But indeed we
> > > missed abstract modifier, which is also quite reasonable as a
> > > precaution for undocumented exploitation.
> > > Let's fix this.
> > >
> > >
> > > >
> > > > Andrew Zhang wrote:
> > > > > On 2/23/06, Nathan Beyer <nbeyer@kc.rr.com> wrote:
> > > > >
> > > > >>
> > > > >> An interesting side note: The "Serialized Form" documentation
> gives away
> > > > >> an
> > > > >> implementation detail of StringBuffer and StringBuilder, in that
> they
> > > > >> both
> > > > >> extend from an AbstractStringBuilder. This might be an
> interesting
> > > > >> approach
> > > > >> to consolidate those code paths.
> > > > >
> > > > >
> > > > > Spec lies sometimes? The spec of StringBuilder and StringBuffer
> claim the
> > > > > superclass of them is java.lang.Object, but the serialized form
> tells the
> > > > > truth - they extend from java.lang.AbstractStringBuilder, which is
> not
> > > > > public.
> > > > >
> > > > > I picked up this thread again because I found an existing
> application
> > > > > failed
> > > > > against Harmony because of this problem. The scenario is:
> > > > > 1. application runs on jdk1.1
> > > > > 2. new instances of some classes. If a class has superclass, then
> new an
> > > > > instance of superclass too if it's not abstract or an interface.
> The
> > > > > pseudo-code looks like:
> > > > > newAllInstances(Class clazz) {
> > > > > if(clazz == null) return;
> > > > > if (clazz is abstract or an interface) return;
> > > > > new an instance of clazz;
> > > > > newAllInstances(clazz.getSuperClass());
> > > > > }
> > > > >
> > > > > The test data includes some instances of StringBuffer. The
> application
> > > > > fails
> > > > > against Harmony because AbstractStringBuilder is a concrete class
> but not
> > > > > public. The application runs well against sun jdk 1.5 (Although
> all code
> > > > > are
> > > > > based on jdk1.1) because the superclass is abstract.
> > > > >
> > > > > So is it a reason to change the signature of class
> AbstractStringBuilder?
> > > > > Make it as abstract really as the name suggests?
> > > > >
> > > > > Thanks!
> > > > >
> > > > >
> > > > >
> > > > >> [1]
> > > > >>
> > > > >>
> http://java.sun.com/j2se/1.5.0/docs/api/serialized-form.html#java.lang.Strin
> > > > >>
> > > > >> gBuilder
> > > > >> [2]
> > > > >>
> > > > >>
> http://java.sun.com/j2se/1.5.0/docs/api/serialized-form.html#java.lang.Strin
> > > > >>
> > > > >> gBuffer
> > > > >>
> > > > >>
> > > > >> -----Original Message-----
> > > > >> From: Tim Ellison [mailto:t.p.ellison@gmail.com]
> > > > >> Sent: Wednesday, February 22, 2006 3:09 PM
> > > > >> To: harmony-dev@incubator.apache.org
> > > > >> Subject: Re: [jira] Resolved: (HARMONY-103)
> java.lang.StringBuilder
> > > > >> Implementation for LUNI
> > > > >>
> > > > >> Nathan,
> > > > >>
> > > > >> First, let me say a big thank you for the code and tests you
> submitted.
> > > > >> I've had a chance to read through it and (beyond the comments
> below) it
> > > > >> looks good.
> > > > >>
> > > > >> I've committed a modified version of your patch to SVN.  However,
> ;-)
> > > > >>
> > > > >> 1.  I've removed the javadoc comments as these appear to be
> direct
> > > > >> copies of the Sun documentation.  We cannot copy Sun's
> property.  For
> > > > >> now the comments have been replaced with TODO tags.
> > > > >>
> > > > >> 2.  I've removed the .intern() from the string literals, since
> these
> > > > >> will be interned by the VM anyway.
> > > > >>
> > > > >> 3.  Why have you got transient char[] and int fields, and then
> serialize
> > > > >> them (as int, char[])?  Wouldn't it be easier to reorder the
> fields and
> > > > >> remove the readObject/writeObject methods?
> > > > >>
> > > > >> Thanks again for your work,
> > > > >> Tim
> > > > >>
> > > > >>
> > > > >> Tim Ellison (JIRA) wrote:
> > > > >> >      [
> http://issues.apache.org/jira/browse/HARMONY-103?page=all ]
> > > > >> >
> > > > >> > Tim Ellison resolved HARMONY-103:
> > > > >> > ---------------------------------
> > > > >> >
> > > > >> >     Resolution: Fixed
> > > > >> >
> > > > >> > Nathan,
> > > > >> >
> > > > >> > Thanks for the patch, it has been applied (minus javadoc)
at
> repo
> > > > >> revision
> > > > >> 379882.
> > > > >> >
> > > > >> > Please check that it has been applied as you expected.
> > > > >> >
> > > > >> >
> > > > >> >> java.lang.StringBuilder Implementation for LUNI
> > > > >> >> -----------------------------------------------
> > > > >> >>
> > > > >> >>          Key: HARMONY-103
> > > > >> >>          URL: http://issues.apache.org/jira/browse/HARMONY-103
> > > > >> >>      Project: Harmony
> > > > >> >>         Type: New Feature
> > > > >> >>   Components: Classlib
> > > > >> >>     Reporter: Nathan Beyer
> > > > >> >>     Assignee: Tim Ellison
> > > > >> >>  Attachments: StringBuilder.java, StringBuilderTest.java
> > > > >> >>
> > > > >> >> This bug is for submitting an implementation of the
> > > > >> java.lang.StringBuilder to the LUNI module of classlib. The
> > > > >> implementation
> > > > >> and class definition is based on the specification at
> > > > >>
> http://java.sun.com/j2se/1.5.0/docs/api/java/lang/StringBuilder.html.
> > > > >> >> The implementation is not complete, there are a few
method
> that are
> > > > >> either incomplete or not implemented. All of these are related
to
> the
> > > > >> Unicode Code Point support, as defined by Java 5. As for the
rest
> of the
> > > > >> implementation, there are probably a number of optimization
> points, but
> > > > >> the
> > > > >> focus was to complete the functionality and make it compatible
> with
> > > > >> various
> > > > >> Java 5 runtimes.
> > > > >> >> Additionally, I had a problem with compiling this class
in
> Eclipse
> > > > >> 3.1.2.
> > > > >> When I set the compiler to Java 1.4 compliance level, the methods
> which
> > > > >> implement the Appendable interface cause compilation errors.
When
> I set
> > > > >> the
> > > > >> compiler to Java 5.0 compliance with Java 1.4 .class file
> compatability
> > > > >> and
> > > > >> Java 1.4 source compatibility, the class compiled fine. I'm not
> sure if
> > > > >> this
> > > > >> is quirk of the JDT compiler or what, but I'm going to do some
> > > > >> investigation
> > > > >> and testing to see if I can isolate it.
> > > > >> >
> > > > >>
> > > > >> --
> > > > >>
> > > > >> Tim Ellison (t.p.ellison@gmail.com)
> > > > >> IBM Java technology centre, UK.
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail:
> harmony-dev-help@incubator.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


-- 
Best regards,
Andrew Zhang

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message