I think it may cause complications protecting the internal character array if String is not final. I suppose the character array could be declared private and final. If not then any subclass would be able to modify the internal character array. Without access to the internal character array then the functionality is limited to that exposed through the Strings public or protected methods. In that case extension functionality may be little different from aggregating a String inside another object or by having external String processing methods on another object. It might not be as neat but using things like static String processor methods and some static imports it could be treated like passing a String to a function. Messing around with things like equality and hash codes could break equality behaviour guarantees and cause problems in all the places where Strings are used as keys or values in collections. Having optimised code for processing Strings in place would require a whole different String implementation that is mutable. As regards a String interface, Java already has a CharSequence interface that tries to in some way achieve this. Perhaps some kind of MutableString class could be introduced that is not a subclass of String but rather is an implementation of CharSequence that makes changes in place. This would allow new code to use the mutable String without accidentally passing it to any existing code that relies on String being immutable. A CharSequence can be converted into a regular immutable String anyway after all. If the code is that performance and memory sensitive then perhaps more of the API's could be modified to work with CharSequence implementations rather than String. It is still possible to write your own CharSequence implementation that is mutable today if you wanted to. On Mar 1, 2:46 pm, Kirk Pepperdine <[email protected]> wrote: > On 2012-03-01, at 3:37 PM, Reinier Zwitserloot wrote: > > > On Thursday, March 1, 2012 12:20:26 PM UTC+1, KWright 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. > > > If String wasn't final, it would obviously not be immutable, duh. > > I can protect the underlying char[] without making the class final. Making > the class final kills all chance of extending which denies developers of the > tools that OO brings to the table. > > 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.
