JADE Project Reborn As Javolution And jScience
dautelle writes "Because of trademark issues we had to rename our Java Addition to Default Environment (JADE) project.
We did a little more than that, we created two new projects with additional features and capabilities: Javolution (javolution.org) and jScience (jscience.org).
Java developers, please update your bookmarks. You may also read the 'Top 10 reasons' why you should consider using Javolution in your current Java project or how you can take part in this immense undertaking that the jScience project represents."
Looking at Text and TextBuilder, I can't help thinking that the interfaces between them and String and StringBuffer are basically the same. Aside from deprecating StringBuffer.capacity(..) method, anyone out there know why the implementations here couldn't simply be folded into the standard JRE/JDK? I realize the library is LGPL, but nothing in Text or TextBuilder appears to be new tech but rather old techniques applied to a new problem.
The strengths of Java are not only in platform consistency but in API consistency. Is there guaranteed behavior of StringBuffer that cannot be handled by TextBuilder?
As for the new interfaces, I wholeheartedly agree with Javalution's moves. Most simply amount to using CharSequence instead of String and this is a change that Sun IMO should have been more aggressive about. It would have broken some code, and I totally understand Sun's historical reluctance to do this, but Java 1.5^H^H^H5.0 did a lot of this anyway with the enum keyword et al. In for a penny, in for a pound.
Maybe next time...
- I don't need to go outside, my CRT tan'll do me just fine.