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: 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 ([EMAIL PROTECTED])
IBM Java technology centre, UK.
--
Best regards,
Andrew Zhang
