Most java projects use a bunch of common classes for various things.
Because this functionality is so common, we tend to copy these common classes from one of our earlier projects.
Instead of just copying some ‘legacy’ snippets from previous projects, it might be a more sensibly thing to use the (Apache) Jakarta Commons libraries instead.
One of the jakarta commons should be mandatory for each Java project: Commons Lang
The commons lang contains all kind of utility classes that will make you think why it is not part of the standard Java lang(uage).
One of the most handy features of the Commons Lang are the Builder classes to easily create toString, equals and hashCode implementations for a class. All these builder classes are smart enough to detail with null and array arguments, so you don’t have to.
Another handy class is the StringUtils class that contains a whole bunch of string functionality like isEmpy / isBlank, trimming, replacing, chomp / chop etc.
When coding I like to aggressively enforce my constructor / method pre-conditions by throwing and IllegalArgumentException when any argument value is not according to a pre-condition. The Validation class will help you with that. It contains utility methods to easily check if the supplied argument isTrue, notEmpty and notNull. Furthermore for a collection / array you can easily validate if there are no null element and that all elements are of a certain type.
There last class I would like to mention is the Enum / ValuedEnum base class.
By extending from this class you can easily create a enum class in Java 1.4 (in Java 5 you should use the new enum language functionality).
I would advise any Java programmer to have a (short) look at the Javadocs of Commons Lang, because besides the features I described above there are a lot more gems to be discovered.
One of the major new features of Java 5.0 is generics. The main purpose of generics is to provide you with a way to make type safe collections, for example, you can specify that your List contains only String objects. The obvious advantages are that the compiler can check at compile time that nothing else than String objects are stored in the List and that you can eliminate a lot of type casts from your source code.
// Old style, not type safe
List names = new ArrayList();
names.add("Jesper");
names.add(new Integer(123)); // not what you meant, but no error or warning
// Java 5.0, using generics
List<String> names = new ArrayList<String>();
names.add("Jesper");
names.add(new Integer(123)); // compiler error
That seems simple enough, but if you study generics in more detail, you will discover that there are some strange limitations that don’t look obvious at first sight.
For example, here is one limitation of generics I would like to highlight: You cannot create an array whose component type is a concrete parameterized type. An example to explain what this means:
// An array of a list of strings. This is illegal, but why?
List<String>[] data = new ArrayList<String>[10];
At first sight, this looks perfectly reasonable. But if you try to compile this, you get an error message, and it isn’t very helpful either:
Jesper.java:6: generic array creation
List<String>[] data = new ArrayList<String>[10];
^
1 error
The compiler just tells you that you can’t do this, but it doesn’t give a hint why. To understand why this is illegal, we have to know a few things about arrays and generics in Java.
First of all, arrays are covariant, which means that an array of supertype references is a supertype of an array of subtype references. For example, Object[] is a supertype of String[], and a string array can be accessed through a reference variable of type Object[].
Object[] example = new String[10]; // ok
example[0] = "Hello World!";
Arrays also carry runtime type information about their component type. At runtime, when you assign a value to an array element, an array store check is performed to check that you’re not storing a value in the array that’s not compatible with its component type. If the check fails, an ArrayStoreException is thrown.
Object[] example = new String[10];
example[0] = new Long(123); // compiles, but throws ArrayStoreException at runtime
That still doesn’t explain why arrays of concrete parameterized types are illegal. There’s one more thing we have to understand, and that is the process of type erasure.
When you compile Java source code in which generic types are used, the compiler does the extra type checks and then translates the code into plain old Java code without generics. If you would decompile the byte code, you would see that the generics have disappeared. So for example List<String> and List<Integer> would both look like the plain old List in the byte code - the information about the generics has been lost by the process of type erasure. The following example illustrates this:
List<String> names = new ArrayList<String>();
List<Integer> values = new ArrayList<Integer>();
System.out.println("Runtime type of 'names': " + names.getClass().getName());
System.out.println("Runtime type of 'values': " + values.getClass().getName());
The output of this piece of code is:
Runtime type of 'names': java.util.ArrayList
Runtime type of 'values': java.util.ArrayList
As you see, both look like plain old ArrayList at runtime. I won’t go into the details here of how and why the compiler handles generics using type erasure.
So here comes the catch. The combination of how arrays work (covariance and runtime type information about the component type) and type erasure for generic types creates a problem when you want to create an array of a concrete parameterized type.
Because of type erasure, there is no exact type information available for the generic type at runtime, so that the array store check doesn’t work, and an unacceptable situation occurs. Here’s an example.
List<String>[] data = new ArrayList<String>[10]; // illegal, but assume that this would be ok
Object[] objArr = data;
objArr[0] = new ArrayList<Integer>(); // should fail, but would succeed
List<String> firstList = data[0]; // would fail with ClassCastException, but there's no cast!
Because of type erasure, List<String> looks like a plain List and ArrayList<Integer> looks like a plain ArrayList at runtime. The array store check would succeed, because ArrayList is a subtype of List. Ofcourse we now end up in an unacceptable situation - the first element of the array now contains an ArrayList<Integer>, which shouldn’t be possible.
To avoid this problem, the Java language engineers at Sun simply decided to make arrays of concrete parameterized types illegal.
Isn’t it ugly that a construct that looks perfectly reasonable (you can make an array of any type, so why not of a concrete parameterized type?) is made illegal essentially because of the way the compiler treats generics? In other words, the language has a hole now because of the implementation details of the compiler.
This is just one of the quirks that you find when you look at generics in depth. You can find a lot of detailed information about generics in Angelika Langer’s Java Generics FAQ.
Some years ago I found out about this class being very usefull in your application. You never used a ThreadLocal? I’ll explain the concept and provide some examples.
So what’s the difference between a thread-local variable and a normal variable? When a thread accesses a thread-local variable it has its own independently initialized copy of the variable. Each thread holds an implicit reference to its copy as long as the thread is alive. So when the thread goes away, all of its thread-local instances are subject to gc.
You typically use an anonymous inner class to provide an initial value (if any) using an appropriate constructor and return the newly constructed object.
You can use this ThreadLocal in several situations:
To keep state with a thread (user-id, transaction-id, logging-id)
Log4j uses this for the NDC (Nested Diagnostic Contexts) feature, you surely need this if you ever want to be able to debug a heavily used production application (some more info here).
My current project uses ThreadLocals to trace incoming and outgoing messages (XML via JMS). When we receive a message we put a pseudorandom 44-bit number into the thread-local variable. Important events (exceptions, any outgoing messages, result of processing) are logged with the value of the thread-local variable. This way we correlate events in the main log of the application.
To cache objects which you need frequently
Another way of using a ThreadLocal is for performance optimalization. You can imagine that there are certain objects which are relatively expensive to initialize, but are not threadsafe. Examples of these objects are XML DocumentBuilders (with XSD validation), and SimpleDateFormat (needs a Calendar instance).
When you put the SimpleDateFormat in a thread-local variable, you don’t have to create a local one for every format operation you need to do (we need them quite often), but still are safe with concurrent processing. Implement this as:
public class DateUtil {
private static final ThreadLocal datetimeFormatter = new ThreadLocal() {
protected Object initialValue() {
return new SimpleDateFormat("yyyyMMdd HHmm");
}
};
public static String toDateTime(Date d) {
SimpleDateFormat sdf = (SimpleDateFormat) datetimeFormatter.get();
return sdf.format(d);
}
}
Watch out
Be careful, do not use thread-local variables as instance variables. Although it is not explicitly stated as such in the SDK API docs, they will cause problems when you don’t use them as static variables. Note that this is still an issue in 1.5.
For you J2EE-addicted, these objects can also be held as instance variable in a SLSB (because they’re accessed by one thread at a time), but I tell you, there are still situations you don’t want to create a Enterprise Bean 
