harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [classlib][lang] AbstractStringBuilder, abstract class?
Date Sat, 07 Oct 2006 15:15:56 GMT
sounds reasonable, but don't go based on my word, of course.

Interesting question is why AbstractStringBuilder isn't abstract...

Andrew Zhang wrote:
> 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.
>>
>>
> 
> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message