The most important feature for Java 7

Pretty much like Microsoft has DLL-hell, Java has JAR-hell.

As developers, you concatenate file names (i.e. xerces.jar, mail.jar) in a classpath and hope that the classes you need are available and that their version is correct. There is no easy way to introspect a JAR file meta-data as extracting the manifest file is not user-friendly (no simple command-line tool) and no one cares to document anything but things like design-time or main-class. It gets really messy if the classpath contains more than one implementation for a given class name and you don’t know it for whatever reason. In that case, classpath order and mechanisms such as placing JAR files in {java.home}/lib/ext (somewhat dangerous) matter. Versioning conflict or namespace collision can be hard to diagnose and fix.

There is also no way for a developer to specify the dependencies between different JAR files using only the JDK, to create say clusters of JAR files. Whether you’re trying to add JSF support to an application server or log4j to your application, your packaging/ANT scripts or IDE project settings (ANT scripts if you’re lucky) are responsible for doing all the work. And this is hard to keep in sync in various development, testing or production environments (that’s why application provisioning tools such as Sun N1 Service Provisioning System are so successful).

To help us poor developers in our daily work, docjar, jarhoo, JarJar, Tom Ball’s latest JFind utility, or some home-grown solution (like trying to catch a ClassNotFoundException on a Class.forName(xxx) with a -verbose:class VM option) are useful band-aids but not a cure for the root cause.

JSR 277 (Java Module System) has been started last June to fix these problems. It is set to provide a distribution format, a versioning scheme, a repository, a runtime support and tools support for modules of Java code.

Part of the solution lies in being able to modify the way classloaders work, but things can be hard to change in a compatible way when you start adding security and native code to the picture. For instance, AFAIK there is currently no way to unload a JNI shared-library or to load it more than once per JVM. So, I’m glad to see people on board this JSR effort such a Stanley Ho, the specification lead and core/deployment guru, Ted Neward with its .Net assemblies experience, Stu Halloway, Hani Suleiman with its discrete but quality contributions to the Java community, etc… (kinda reads like a list of recently Google-hired employees ;-).

There are already a few component models out there: Eclipse/OSGi plugins and NetBeans modules are obvious examples where modular development has proven to be very successful. But that’s both part and beyond the problem this JSR is trying to fix IMHO. The deployment part is not addressed, the solution needs to be baked into the JVM/JRE (not depend on Eclipse RCP or the NetBeans Platform) but it is not addressing application-level component development. JSR 277 is both very ambitious and very exciting even if Cedric Beust doesn’t seem to recognize it is a step in the right direction. Maybe “Java Component Object Model” and “Java Module System” are two different unrelated things but I believe there’s a lot of commun ground and I guess Cedric would be a good addition to the above list of participants.

JSR 277 is set to be part of Dolphin, aka Java 7. Whether it’s about Desktop Java or server-side Java, to me that’s the most important feature planned so far (XML at the language level is a close second).

Author: alexismp

Google Developer Relations in Paris.