Seems like it was just a oversight. I can check in a fix.
-Nathan
On 10/7/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
2006/10/7, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
> 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
> >> Sent: Wednesday, February 22, 2006 3:09 PM
> >> To: [email protected]
> >> 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 ([EMAIL PROTECTED])
> >> IBM Java technology centre, UK.
> >>
> >>
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
