harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <nbe...@kc.rr.com>
Subject RE: [jira] Resolved: (HARMONY-103) java.lang.StringBuilder Implementation for LUNI
Date Thu, 23 Feb 2006 04:48:38 GMT
1. Javadoc - Yeah, I didn't know what was the right thing to do in regards
to the javadoc. It wasn't 100% copy and paste, but the class-level and some
of the methods were pulled. My thought was that if we're considering the
Javadoc as the specification for the interface, then it was fair game. I
know this was discussed a bit earlier on the list, but I don't recall any
real resolution. I'll checkout the code an insert original comments. Let me
know if there are any guidelines I should follow.

2. String.intern() - Cool, sounds good.

3. Serialization - I did this for two reasons: one, this has been my
personal practice for writing serialization code, as I prefer to have more
control over serialization and to have it be more explicit (much of this
comes out of suggestions in Effective Java); two, when I read the
'Serialized Form' in the Javadoc for StringBuilder [1] and compared that
against StringBuffer [2], this seemed liked the contract. The StringBuffer
doc has both readObject/writeObject AND serialized fields, whereas the
StringBuilder doc only has readObject/writeObject information. Maybe my
understanding of the Javadoc tools is off, but I assumed that since there
weren't any fields there, they were transient.

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.

Related Question:
All of the exceptions that are thrown don't use any messages. Can and should
we use the "com.ibm.oti.util.Msg" class for retrieving some localized
messages for those exceptions? I personally find it helpful for exceptions,
like NPEs, etc, to have some indication of the real issue. Use of that Msg
class may not be appropriate in all cases, I guess, as you wouldn't want to
introduce some runtime circular execution dependency.


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


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