Big applications have a tendency to accumulate enormous
classpaths. Looking at such a classpath, you might be hard put to
know whether any given jar is really needed. Perhaps it was
needed at the time it was added, but that need has long since
evaporated. How can you tell? Kyrill Alyoshin has an elegant
I was using this Java idiom today, not for the first time, and thought I'd blog it for people not aware of it. You probably know that if you compare two objects x and y using x.equals(y), the result will be false if they are distinct arrays, even if their contents are the same. There is an easy way to get the right result for arrays.
Sometimes you need to clone objects, and sometimes you can't
use their clone method, and sometimes serialization provides an
alternative. Here's an explanation of when you might need this
exotic and expensive technique, and how you can use it.
If you've ever made a serious effort to get rid of "unchecked" warnings from the Java compiler (the ones it gives you with -Xlint:unchecked) then you'll probably have found some cases where you know a cast is correct but you can't convince the compiler of it. Is there anything better than adding @SuppressWarnings("unchecked") around the whole method?
Sometimes static code isn't enough and you need to build code
dynamically, at run time. That's usually a hefty proposition,
but if the code you need to build is just an interface, it's
actually relatively simple. Here are some of the reasons you
might want to build interfaces at run time and how you might go
There are tons of books and articles about how to design and write good Java code, but surprisingly little about the specific topic of API design. On my artima.com blog I wrote a summary of what I've learnt on the subject from various sources and my own experience.