On 10/7/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
sounds reasonable, but don't go based on my word, of course.
Interesting question is why AbstractStringBuilder isn't abstract...
curious too...
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]
--
Best regards,
Andrew Zhang
