I have just started working on a new branch of Commons::Net which will be a Tiger (Java 5.0) based implementation. This will not require huge changes, but will clear the decks for some of the following features:
- Removal of all extra dependencies (currently Jakarta ORO is the regular expression implementation used in Commons::Net. It has done and still does a fine job, and the JDK has only matched its functionality in release 5.0. However, the less extra dependencies, the better).
- JCE-based secure cipher and channel implementations without having to include the extra JSSE jar.
- A cleanup of some of the more gnarly threading and I/O code. Some of the concurrency classes may come in useful here. I was originally thinking that NIO may be a good option to look at here, however now, I am less convinced. I think the extra complexity may be too much for the potential gains, which would be small, if any. I believe that NIO is a great candidate for a certain class of server applications that may from time to time require a large amount of resources and the ability to handle severe load gracefully. A good case in point would be an application like Azureus (and they do indeed use NIO heavily). For a small synchronous-I/O client-side library like Commons::Net, it would probably just complicate the code with no real performance gains.
- Some nice syntactic sugar like generics/compile-time type checking and enhanced for/iterator loops.
- Miscellaneous items, such as this code which FindBugs located for me:
public DatagramPacket getDatagramPacket()
{
if (dp == null)
synchronized(this) {
if (dp == null) {
dp = new DatagramPacket(buf, buf.length);
dp.setPort(NTP_PORT);
}
}
return dp;
}Previous to JDK 5, this double-checked lock idiom would not be guaranteed to work. However, by marking the dp variable as
volatile, the new Java memory model will enforce the correctness of this block of code.
I have also migrated the existing Maven 1 build setup to a Maven 2-based project. Apart from some minor annoyances (like the alpha-state Plexus plugins not being available where they should be), it was quick and easy to get going. I have always liked Maven, and Maven 2 looks like good improvement. It’s under quite heavy development at the moment (as the Apache SVN logs show), but at least the documentation for version 2 is a big improvement over version 1. In particular, the JIRA changelog report is very neat. I haven’t scratched the surface yet of what Maven 2 is capable of, but I’m hoping to have a good look at it over the next month or so.