Aus http://commons.apache.org/lang/article3_0.html:
What’s new in Commons Lang 3.0?
Commons Lang 3.0 is (not yet) out, and the obvious question is: "So what? What’s changed?".
The big story
Lang is now Java 5 based. We’ve generified the API, moved certain APIs to support
varargsand thrown out any features that are now supported by Java itself. We’ve removed the deprecated parts of the API and have also removed some features that were deemed weak or unnecessary. All of this means that Lang 3.0 is not backwards compatible.To that end we have changed the package name, allowing Lang 3.0 to sit side-by-side with your previous version of Lang without any bad side effects. The new package name is the exciting and original
org.apache.commons.lang3.There are also, as you’d expect, new features, enhancements and bugs fixed.
The build
We built 3.0 using Maven 2.2.1 and Java 1.5. Needs confirmation before release of actual build details
Migrating from 2.x
Despite the label of backwards incompatibility, in the vast majority of cases the simple addition of a
'3'to an import statement will suffice for your migration. For example, using Perl:find . -type f -name ‚*.java‘ | xargs perl -pi -e ’s/org\.apache\.commons\.lang\./org.apache.commons.lang3./g‘
Maven users will need to update the groupId from
commons-langtoorg.apache.commons, and the artifactId fromcommons-langtocommons-lang3.What’s gone?
Enum package – Java 5 provided enums out of the box, therefore we dispensed with both the deprecated enum package, and the enums package. Instead you should migrate over to the standard Java enum. An EnumUtils class has been born from the ashes of the old code, focused on providing additional functionality to the standard Java enum API.
NestedExceptions – In Java 1.4, the notion that all Throwables could be linked to a cause was introduced. In Lang we had provided a NestedException framework to support the same feature, and now that we’re jumping from Java 1.3 to Java 5 we are remove this feature. The deprecation section below covers one part of ExceptionUtils that remains until we are on Java 6, where the last remaining parts of the JDK appear to have embraced the new cause API.
JVMRandom – This class was introduced in Lang 2.0 to support a Random object built around the system seed. This proved to be both an uncommon use case and one with bugs and so was dropped.
StringEscapeUtils.escapeSql – This was a misleading method, only handling the simplest of possible SQL cases. As SQL is not Lang’s focus, it didn’t make sense to improve this method.
Various Exception classes were removed – the lesson in defining more semantically relevant exception classes is that you can keep on coming up with more and more new classes. Simpler to focus on using the main JDK classes.
The various Range classes in the
mathpackage were removed in favour of a new Range class.All deprecated fields/methods/classes – with a new major version, all of the previously deprecated parts of the API could finally go away.
If you feel that something was unfairly taken away, please feel free to contact the list. In many cases the possibility exists to reintroduce code.
Deprecations
The lone deprecation in 3.0 is that of the notion of ‚cause method names‘ in ExceptionUtils. In Java 5.0 it is still just about needed to handle some JDK classes that have not been migrated to the getCause API. In Java 6.0 things appear to be resolved and we will remove the related methods in Lang 4.0.
New packages
Two new packages have shown up. org.apache.commons.lang3.concurrent, which unsurprisingly provides support classes for multi-threaded programming, and org.apache.commons.lang3.text.translate, which provides a pluggable API for text transformation.
TODO: Add examples
New classes
CharSequenceUtils
EnumUtils
Pair
Range
builder.Builder
exception.ContextedException
exception.CloneFailedException
reflect.ConstructorUtils
reflect.FieldUtils
reflect.MethodUtils
reflect.TypeUtils
text.WordUtilsNew methods
What’s fixed in Lang 3.0?
Weitere Änderungen: http://commons.apache.org/lang/upgradeto3_0.html.
So und wann kommt nun Common Collections für Java 5?
Sehr ſchön, was lange währt … was mich jetzt intereſſieren würde, wäre ein Vergleich zwischen Commons Lang 3 und Guava („Google Collections 2.0“) – beide erweitern die Java-Standardbibliothek um ſinnvolle (aber ähnliche) Funktionalität.
Bei neuen Projekten würde ich eher zu Guava tendieren … ¿andere Meinungen? Oder gibt es gar Projekte, die gleich beide einſetzen?
Einen Port von Collections für Java5 gibt es, basiert 1:1 auf dem alten Code. Mit seinen Vor- und Nachteilen.
http://larvalabs.com/collections/
Für neuen Code finde ich Google Collections auch super. Da ist eigentlich alles drin was man so braucht.