You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by "Nathan Beyer (JIRA)" <ji...@apache.org> on 2006/02/19 20:58:36 UTC
[jira] Created: (HARMONY-103) java.lang.StringBuilder
Implementation for LUNI
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
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-103) java.lang.StringBuilder
Implementation for LUNI
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-103?page=comments#action_12367793 ]
Tim Ellison commented on HARMONY-103:
-------------------------------------
Thanks Nathan,
Applied in LUNI module java.lang.StringBuilder at repo revision 381015.
Please check is was 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, StringBuilder_javadoc_patch.txt
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (HARMONY-103) java.lang.StringBuilder
Implementation for LUNI
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-103?page=all ]
Tim Ellison reassigned HARMONY-103:
-----------------------------------
Assign To: Tim Ellison
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-103) java.lang.StringBuilder
Implementation for LUNI
Posted by "Nathan Beyer (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-103?page=all ]
Nathan Beyer updated HARMONY-103:
---------------------------------
Attachment: StringBuilder_javadoc_patch.txt
Here's a patch for the Javadoc to StringBuilder. This time it's 100% of my own creation.
> 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, StringBuilder_javadoc_patch.txt
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Resolved: (HARMONY-103) java.lang.StringBuilder Implementation
for LUNI
Posted by Tim Ellison <t....@gmail.com>.
Nathan Beyer wrote:
> 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.
Thanks Nathan. Now that you have implemented the code you should be in
a good position to go back and fill in the javadoc comments describing
what the methods do.
The guidelines are simply to write useful doc in your own words,
following the usual javadoc conventions for @param, @return, @throws, etc.
> 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);
Ok, as you can see I left in the readObject/writeObject methods. IMHO
where our implementation has the same serialized form as the spec calls
for, then we should just let nature take it's course.
> 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.
As you know, implementing the customer read/write allows you to store in
whatever form you choose. It looks like your impl is doing the right
thing (I haven't tested it), but I think you could also do it without
the read/write. It's not a big deal.
> 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.
Yep (and possibly the reason why there is a custom read/write on the
reference impl).
> 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.
Yes. The messages are currently centralized in LUNI, but they should be
distributed out to the modules so they all localize themselves. In the
meantime choose a good message from the list, or add a new one with
message key >KA000.
Thanks again,
Tim
p.s. send more code ;-)
> [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.
[classlib] javadoc (the comments not the tool) (was: Re: [jira]
Resolved: (HARMONY-103) java.lang.StringBuilder Implementation for LUNI)
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr wrote:
>
>
> Nathan Beyer wrote:
>> 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.
>
> Here's the rule - don't copy Sun's spec material as it's copyrighted
> work and while using it in this way is arguably fair use, Sun has
> specifically said no to this, and it's not worth the fight.
>
> Here's the guidlines I'd like to see :
>
> 1) if it's org.apache.harmony, do whatever you want
Yep. Though if the type/method is not internal you should do a
reasonable job so other module developers can use your code.
> 2) if it's java[x].* and you want to do javadoc, please put a pointer to
> the relevant Sun spec, and then go to town...
I'd say just go to town and write a good javadoc comment -- we can add
in the link to Sun's spec document automagically at javadoc creation
time since the mapping between the two is well understood.
Regards,
Tim
> geir
>
> (next time, can you try to interleave your response with what you are
> responding to if it's multi subject? Helps those of us that are
> catching up...)
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [jira] Resolved: (HARMONY-103) java.lang.StringBuilder Implementation
for LUNI
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Nathan Beyer wrote:
> 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.
Here's the rule - don't copy Sun's spec material as it's copyrighted
work and while using it in this way is arguably fair use, Sun has
specifically said no to this, and it's not worth the fight.
Here's the guidlines I'd like to see :
1) if it's org.apache.harmony, do whatever you want
2) if it's java[x].* and you want to do javadoc, please put a pointer to
the relevant Sun spec, and then go to town...
geir
(next time, can you try to interleave your response with what you are
responding to if it's multi subject? Helps those of us that are
catching up...)
RE: [jira] Resolved: (HARMONY-103) java.lang.StringBuilder Implementation for LUNI
Posted by Nathan Beyer <nb...@kc.rr.com>.
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.
[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.
Re: [jira] Resolved: (HARMONY-103) java.lang.StringBuilder Implementation
for LUNI
Posted by Tim Ellison <t....@gmail.com>.
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.
[jira] Resolved: (HARMONY-103) java.lang.StringBuilder
Implementation for LUNI
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-103) java.lang.StringBuilder
Implementation for LUNI
Posted by "Nathan Beyer (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-103?page=comments#action_12367113 ]
Nathan Beyer commented on HARMONY-103:
--------------------------------------
Well, I've figured the compile issue I was having. The StringBuilder API assumes Java 5 covariance capabilities, which is how it uplifts the methods in Appendable to be StringBuilder. I logged a bug with the Eclipse JDT and it was a bug in the Java 5 compiler that allowed covariance to be used when Java 1.4 bytecode was requested. Here's the bug report, which has already been fixed: https://bugs.eclipse.org/bugs/show_bug.cgi?id=128560.
As such, if we need to continue using a Java 1.4 compliant compiler, then we'll either need to remove the "implements Appendable" or change the return types to "Appendable". Since the end goal would be to get to the proper method signature, I would propose just removing the "implements Appendable" until we can move to a Java 5 compiler.
> 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
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-103) java.lang.StringBuilder
Implementation for LUNI
Posted by "Nathan Beyer (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-103?page=all ]
Nathan Beyer updated HARMONY-103:
---------------------------------
Attachment: StringBuilder.java
The actual java.lang.StringBuilder class.
> 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
> Attachments: StringBuilder.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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-103) java.lang.StringBuilder
Implementation for LUNI
Posted by "Nathan Beyer (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-103?page=all ]
Nathan Beyer updated HARMONY-103:
---------------------------------
Attachment: StringBuilderTest.java
JUnit test case for StringBuilder. I've run this test against Sun's JRE 5.0_5 and BEA's JRE 5.0_4_R26.0 and this test passes with one exception with the "insert(int, char)" method, which based on the API specification I would consider a bug, but how this is handled in Harmony is up for debate.
Note: I was unable to test the serialization, as from what I can tell the current Harmony snapshots don't support it. I was getting a NoSuchAlgorithm for the MesageDigest SHA. However, I do believe the the serialization is implemented correctly, at least according to the specification.
> 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
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira