XAML4J: Jelly gets new life Scared of annotation hell
Jul 02

Java 5: java.lang.StringBuilder

Tech Add comments

It is still weird for me to say “Java 5″. Version numbers are so meaningless these days. I only just saw that JDK 1.5 has this SpringBuilder which is basically the same as StringBuffer apart from the fact that it doesn’t guarantee synchronization, and hence it isn’t thread safe.

This is fine for the majority of uses though, so will become the norm, and StringBuffer will become legacy (like Hashtable and HashMap).

I do hope we have a future Java version which cleans up all of these things (I know backwards compatibility is good, but at SOME point it would be nice to get rid of the baggage). Our world could be so much cleaner. Real Dates (immutable), one set of Collections, one StringBuffer which you can make thread-safe or not as the case may be, and many many more. I wonder if we will ever get this… and will it be Java 100?

4 Responses to “Java 5: java.lang.StringBuilder”

  1. Sumit Says:

    R.J., I believe what Dion meant was an analogy with the case of Hashtable and HashMap, where the introduction of HashMap made Hashtable legacy. Similarly, StringBuilder makes StringBuffer legacy.

  2. Hawk Says:

    I believe there’s also an issue with StringBuilder supporting Unicode 4.0. The inference was that StringBuffer only supported up to 3.0.

  3. Gaëtan Sheridan Says:

    Unfortunately, despite their identical signature, StringBuilder and StringBuffer do not implement a common interface which makes retrofitting existing code much harder that it needs to be…

  4. anonymous Says:

    At this point the baggage is quite heavy. There are already about 100 COBRA classes that should never have made it into JSE and tons of legacy classes and deprecated crap. I agree that Java just has to let go of it all.

    Also, the unicode situation is troubling: your app is no longer fully accessible if it assumes a character is a char, as a character may be stored in two chars. As a char is internally stored and manipulated as an int, it might have been better (albeit very heavy handed) to make a char an unsigned int. Backwards compatibility could be maintained in almost all situations (you shouldn’t be doing arithmetic with a char anyway…).

Leave a Reply

Spam is a pain, I am sorry to have to do this to you, but can you answer the question below?

Q: Type in the word 'cricket'