On 10/8/06, Nathan Beyer <[EMAIL PROTECTED]> wrote:
I commited a change. The class is now abstract. Please verify that is solves the issue.
Thank you Nathan, it works fine now! Would someone mind posting a JIRA issue with an additional test for
StringBuffer and StringBuilder. -Nathan On 10/7/06, Nathan Beyer <[EMAIL PROTECTED]> wrote: > Seems like it was just a oversight. I can check in a fix. > -Nathan > > On 10/7/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote: > > 2006/10/7, Geir Magnusson Jr. <[EMAIL PROTECTED]>: > > > sounds reasonable, but don't go based on my word, of course. > > > > > > Interesting question is why AbstractStringBuilder isn't abstract... > > > > It does not really matters from implementation POV, and the name was > > just chosen after the RI - sorta be deeply compatible. But indeed we > > missed abstract modifier, which is also quite reasonable as a > > precaution for undocumented exploitation. > > Let's fix this. > > > > > > > > > > Andrew Zhang wrote: > > > > On 2/23/06, Nathan Beyer <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > > > >> 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 ([EMAIL PROTECTED]) > > > >> IBM Java technology centre, UK. > > > >> > > > >> > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Best regards, Andrew Zhang