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?
July 2nd, 2004 at 4:11 pm
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.
May 20th, 2005 at 4:25 pm
I believe there’s also an issue with StringBuilder supporting Unicode 4.0. The inference was that StringBuffer only supported up to 3.0.
September 8th, 2005 at 10:50 am
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…
May 30th, 2006 at 11:28 am
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…).