harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [jira] Resolved: (HARMONY-103) java.lang.StringBuilder Implementation for LUNI
Date Wed, 22 Feb 2006 21:09:19 GMT

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 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.

View raw message