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]
