harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Zhang" <zhanghuang...@gmail.com>
Subject [classlib][lang] AbstractStringBuilder, abstract class?
Date Sat, 07 Oct 2006 14:51:30 GMT
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.
>
>


-- 
Best regards,
Andrew Zhang

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