I guess that interface would have to be CharSequence. But it isn't as useful as it could be because so many methods only accept and return Strings, instead of CharSequences.
On 1 March 2012 11:36, Kirk Pepperdine <[email protected]> wrote: > > > The questionable decision there wasn't making them final, but giving them > a broken hashCode implementation. > > > I often wish I could extend String to provide a more useful String that > all of my code could use. In fact, I wonder if String shouldn't have been > an interface so I could have ASCIIString, UTF8String, and so on. Might even > be able to get rid of utility classes like StringBuilder and StringBuffer... > > Kirk > > -- > Skype: ricky_clarkson > > > On Thu, Mar 1, 2012 at 8:20 AM, Kevin Wright <[email protected]>wrote: > >> I never really had a big problem with String being final, although the >> claims that it was for security reasons seem a bit weak given that strings >> are also immutable. >> >> On the other hand, making enums and the URL type final after giving them >> both such a hideously broken hashCode implementation... That definitely >> numbers amongst the top 10 questionable design decisions in Java. >> >> >> On 1 March 2012 11:14, Kirk Pepperdine <[email protected]> wrote: >> >>> >>> On 2012-03-01, at 12:08 PM, Fabrizio Giudici wrote: >>> >>> > On Thu, 01 Mar 2012 12:01:46 +0100, Kirk Pepperdine < >>> [email protected]> wrote: >>> > >>> > >>> >> On the question of Strings, StringBuffer/Builder and copying char >>> arrays. Sorry to say that this is still a huge performance drain in many >>> applications. It's the only place where I miss c pointers ;-). Hotspot >>> rarely does the right thing when it comes to string and string >>> manipulation. It's javac that makes the biggest impact (string1 + string2 >>> is converted to using StringBuilder and so on). So here are a few rules >>> when working with strings. >>> >> >>> >> Rule #1, don't copy them or force them to copy themselves. >>> >> Rule #2, use a flyweight instead of a copy >>> >> Rule #3, don't copy them or force them to copy themselves. >>> >> Rule #4, use System.arraycopy, it is the most efficient way to copy a >>> primitive array. >>> > >>> > Perhaps does this explain why e.g. Perl is still faster than Java in >>> some heavy text manipulation benchmarks? (not my direct experience, I'm not >>> using Perl since a lot of time, this assertion just came up a few weeks ago >>> in a JUG discussion out of a reputable commenter). >>> >>> I'm not sure how Perl treats strings but if it runs though it a char at >>> a time without copying... perfect.... it will beat the cr@p out of >>> Java. Not only a Java problem, I think Dick mentioned Smalltalk. Smalltalk >>> was also horrible with Strings. It's only saving grace was that String >>> wasn't a final class which meant you could extend it in some very useful >>> ways that mitigated the copy costs. Having String declared final by some >>> developer in Santa Clara wanting to be my mother is one of my top pet >>> peeves... ;-) >>> >>> Regards, >>> Kirk >>> >>> -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
