0 comments
Java 
What Java still lacks is a standardized module system to describe and manage dependencies with. This often leads to "jar hell", a jungle of jars needed on all kinds of locations, hard to manage classloaders and all kinds of ad-hoc dependency declaration mechanisms like Maven and Ivy.
Sun has worked for a while on JSR 277, a new standard for declaring and using modules in the Java platform. A module would be a jar with some extra information on its identity, version number, dependencies, etc. JSR 277 always was controversial, because a similar specification already exists: JSR 291 or OSGi. OSGi originated in embedded development, but is now widely used in mobiles, the Harmony Java VM, Eclipse products, Spring and most application servers, including the new Sun Glassfish v3 server. Where JSR 277 demanded additional language and runtime features, OSGi runs in Java 1.1 and up using the basic metadata and classloader features already available, and can host other languages as well.
Mark Reinhold blogs about a new project Jigsaw that will provide modularity support for the Java platform. The JSR 277 project will be discontinued. As announced in they blog Jigsaw will NOT be part of the official Java specification. That means Java VMs of IBM and Oracle (JRockit) do not need to support it. If Jigsaw will make the cut for Java 7 is not decided yet.
To me, a Java module system (like .NET already has for years) was the most important new feature of Java 7. Now that it is dropped, I think OSGi will become even more popular. It is an official specification, works today and already has tool support, like the Eclipse PDE and the Maven Tycho plug-ins. Products like server-side equinox and Spring DM server are already available, providing Java EE container support for modules. By the time that Sun finally decides on a module system for Java, will it really matter?