Subject: RE: [jira] Resolved: (HARMONY-103) java.lang.StringBuilder Implementation for LUNI - msg#01009

Previous Message by Date: click to view message preview

Re: [jchevm] -- for some reason, apache won't let me attach a file

Thanks for the help. It looks like JIRA is working again. Yesterday JIRA would not accept a zip file. Weldon On 2/22/06, Richard Liang <richard.liangyx@xxxxxxxxx> wrote: > yes, please sign up and log in to JIRA, then you can describe what your > question is and attach files. :-) > > Richard Liang > China Software Development Lab, IBM > > > > Tim Ellison wrote: > > Please, don't send attachments to the mailing list. > > > > Attach them to a JIRA. > > > > Regards, > > Tim > > > > Weldon Washburn wrote: > > > >> Does anyone have suggestions? > >> Thanks > >> Weldon > >> > >> ---------- Forwarded message ---------- > >> From: Mail Delivery Subsystem <mailer-daemon@xxxxxxxxx> > >> Date: Feb 22, 2006 10:52 AM > >> Subject: Delivery Status Notification (Failure) > >> To: weldonwjw@xxxxxxxxx > >> > >> > >> This is an automatically generated Delivery Status Notification > >> > >> Delivery to the following recipient failed permanently: > >> > >> harmony-dev@xxxxxxxxxxxxxxxxxxxx > >> > >> Technical details of permanent failure: > >> PERM_FAILURE: SMTP Error (state 12): 552 Message rejected as it is spam > >> (body) > >> > >> ----- Original message ----- > >> > >> Received: by 10.35.78.13 with SMTP id f13mr853709pyl; > >> Wed, 22 Feb 2006 10:51:39 -0800 (PST) > >> Received: by 10.35.58.1 with HTTP; Wed, 22 Feb 2006 10:51:39 -0800 (PST) > >> Message-ID: <4dd1f3f00602221051w2681f2bbwdc19d809295edba0@xxxxxxxxxxxxxx> > >> Date: Wed, 22 Feb 2006 10:51:39 -0800 > >> From: "Weldon Washburn" <weldonwjw@xxxxxxxxx> > >> To: harmony-dev@xxxxxxxxxxxxxxxxxxxx > >> Subject: [jchevm] rough draft of Harmony Class Lib to GNU native methods > >> glue > >> MIME-Version: 1.0 > >> Content-Type: multipart/mixed; > >> boundary="----=_Part_12265_10263947.1140634299199" > >> > >> ------=_Part_12265_10263947.1140634299199 > >> Content-Type: text/plain; charset=ISO-8859-1 > >> Content-Transfer-Encoding: quoted-printable > >> Content-Disposition: inline > >> > >> Archie, Tim, > >> > >> Attached is a zip file containing a first cut at gluing Harmony Class > >> Library to the native methods exposed by JCHEVM. I call this glue, > >> "kernel_path". So far, no mods have been made to any JCHEVM files. > >> > >> ----- Message truncated ----- > >> > >> > >> > >> -- > >> Weldon Washburn > >> Intel Middleware Products Division > >> > >> > > > > > > -- Weldon Washburn Intel Middleware Products Division

Next Message by Date: click to view message preview

[jira] Created: (HARMONY-123) Refactor: java.nio.charset.CharsetDecoder.decode

Refactor: java.nio.charset.CharsetDecoder.decode ------------------------------------------------ Key: HARMONY-123 URL: http://issues.apache.org/jira/browse/HARMONY-123 Project: Harmony Type: Bug Components: Classlib Reporter: Richard Liang Priority: Minor I've refactored two decode methods in CharsetDecode.java. Although the original version runs well, the structure of these two methods is messed. The refactored methods include: 1. public final CharBuffer decode(ByteBuffer in) throws CharacterCodingException; 2. public final CoderResult decode(ByteBuffer in, CharBuffer out,boolean endOfInput); Main changes: 1. remove embedded "while" in decode(ByteBuffer in, CharBuffer out,boolean endOfInput); 2. restruct condition control process in both two methods. 3. truncate return value of decode(in), which means the returned CharBuffer has the same value between capacity and limit. -- 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

Previous Message by Thread: click to view message preview

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@xxxxxxxxx) IBM Java technology centre, UK.

Next Message by Thread: click to view message preview

Re: [jira] Resolved: (HARMONY-103) java.lang.StringBuilder Implementation for LUNI

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@xxxxxxxxx] > Sent: Wednesday, February 22, 2006 3:09 PM > To: harmony-dev@xxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxx) IBM Java technology centre, UK.