Interessant zu lesen, wie Last.fm Java (und auch C++) in ihrem Backend nutzt: http://java.dzone.com/articles/case-study-how-lastfm-uses. HornetQ ist die JMS-Implementierung von JBoss 6.

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-lang to org.apache.commons, and the artifactId from commons-lang to commons-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 math package 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.WordUtils

New 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?

Wenn man von Spring kommt ist man gewöhnt, dass es ein Lebenszyklus gibt insbesondere mit

• @PostConstruct

Standardmäßig gibt es das mit Guice nicht und das ist ziemlich ungünstig, insbesondere wenn man Spring-Projekte migrieren möchte. (Siehe Diskussion http://code.google.com/p/google-guice/issues/detail?id=62)

Allerdings gibt es http://code.google.com/p/guiceyfruit/. Das bildet den Lebenszkylus, vorgeschrieben durch Annotationen (http://code.google.com/p/guiceyfruit/wiki/Annotations), nach. Es wird einfach als Modul mit hinzugenommen, etwa so:

Injector injector = Guice.createInjector( new Jsr250Module(), new MEINModule() );

Mit paketsichtbaren Methoden gibt es aber Probleme: Sie müssen public sein.

Von Wikipedia:

In the end of 2009, iText version 5 is released under Affero GPL license. This license is drastically different from the previous license that iText had been

distributed under, in that it requires anyone using iText 5 under a free license to provide the users with the full source of their application. Projects that do not want to provide their source code are required to purchase a commercial license for a non-disclosed price or they cannot upgrade to iText 5. (Projects can continue using previous versions of iText under the more liberal license without any changes.)

Siehe auch:

• http://itextpdf.com/terms-of-use/
• http://itext-general.2136553.n4.nabble.com/Silent-license-change-td2156060.html
• Dazu auch http://java.dzone.com/tips/java-pdf-tools-alternatives und Brunos Bemerkungen. Und alles Gute für einen Sohn.

1. XML-Prolog schreiben

Das kann XStream nicht, aber beim Lesen wird der XML-Prolog überlesen. Man muss den Prolog also von Hand in den Strom schreiben:

Writer w = new OutputStreamWriter(
new BufferedOutputStream(
new FileOutputStream( file ) ), „utf-8“ );
w.write( „<?xml version=\“1.0\“ encoding=\“utf-8\“?>\n“ );
xstream.toXML( value, w );
w.close();

2. Statt voll qualifizierte Klassenamen kann ein anderer Name mit alias() auf dem XStream-Objekt gesetzt werden.

xstream.alias( „Course“, Course.class );
xstream.alias( „Contact“, Contact.class );

3. Statt geschachtelte Elemente sollen gewisse Dinge in Attributen stehen:

xstream.useAttributeFor( TrainerCourse.class, „price“ );
xstream.useAttributeFor( TrainerCourse.class, „languages“ );

4. Statt Elemente von Sammlungen in ein eigenes Container-Element zu setzen, kann das auch ohne Überelement gesetzt werden:

xstream.addImplicitCollection( Trainer.class, „trainerCourses“ );

5. Gewisse Dinge sollen anders geschrieben werden. Konverter sind angebracht:

xstream.registerConverter( new TrainerCourseConverter() );
xstream.registerConverter( new YYYYMMDDConverter() );

Konverter können ganz eigenständig entwickelt werden (1. Bsp.), oder eine Basisklasse (2. Bsp.) vereinfacht das:

class TrainerCourseConverter implements Converter
{
@Override
public void marshal( Object value, HierarchicalStreamWriter writer, MarshallingContext arg2 )
{
TrainerCourse tc = (TrainerCourse) value;
writer.addAttribute( „courseCode“, c.getCourseCode() );
}

@Override
public Object unmarshal( HierarchicalStreamReader arg0, UnmarshallingContext arg1 )
{
…
}

@SuppressWarnings( „unchecked“ )
@Override
public boolean canConvert( Class clazz  )
{
return clazz.equals( TrainerCourse.class );
}
}

Zweiter einfacher Konverter:

class YYYYMMDDConverter extends AbstractSingleValueConverter
{
@SuppressWarnings( „unchecked“ )
public boolean canConvert( Class clazz )
{
return clazz.equals( Date.class );
}

@Override
public Object fromString( String str )
{
return StringUtils2.isEmpty( str ) ? null : DateUtils.parseDDMMYYYY( str );
}

@Override
public String toString( Object obj )
{
return obj == null ? „“ : DateUtils.formatDDMMYY( (Date) obj );
}
}

6. Elemente mit bekannten Namen sollen in einer CDATA-Umgebung geschrieben werden:

xstream = new XStream( new XppDriver() {
public HierarchicalStreamWriter createWriter( Writer out ) {
return new PrettyPrintWriter( out ) {
boolean isCDATA = false;
@SuppressWarnings( „unchecked“ ) @Override public void startNode( String name, Class clazz ) {
super.startNode( name, clazz );
isCDATA = name.equals( „contents“ ) || name.equals( „description“ );
}
@Override protected void writeText( QuickWriter writer, String text ) {
if ( isCDATA ) { writer.write( „<![CDATA[\n“ ); writer.write( text ); writer.write( „\n]]>“ ); }
else super.writeText( writer, text );
}
};
}
} );

7. XStream soll XML-Dateien selbst laden und speichern (http://xstream.codehaus.org/persistence-tutorial.html)

Verwaltet man viele kleine XML-Dokumenten, etwa Kontakte, kann XStream diese XML-Kontakt-Dateien automatisch anlegen, lesen und aktualisieren. Der Tick ist, dass man alle Daten in eine spezielle Map, Set oder List setzt. Die XStream-Implementierungen der add(), put(), get(), … Methoden sind so realisiert, dass die Daten beim add()/put() in die Datenstruktur und gleichzeitig XML-serialisiert als Datei ins Dateisystem kommen. In welches Verzeichnis sagt die FilePersistenceStrategy.

PersistenceStrategy strategy = new FilePersistenceStrategy(new File(„/tmp“));
Map  map= new XmlMap( strategy );

Die Dateinamen sind etwas merkwürdig, etwa long@12345676, aber dass ist kein Wunder, denn der Dateiname kodiert den Schlüssel, denn XStream muss ja bei einem get() etwa die XML-Datei wiederfinden.