Update on Java Modules
Glyn Normington has written an overview of Java modularity covering JSR 277, JSR 291 and JSR 294. He describes how each is different and adds value, and later responds to the question of why we need modularity support in the JVM, as opposed to custom classloaders (like OSGi).
Normington stars by recaping the three specifications, along with where his personal involvement are and his biases. He describes the three specifications:
JSR 277 is trying to create a static module system for Java 7. JSR 291 is referencing and extending the already mature OSGi dynamic component system while maintaining compatibility with JSR 232 which did a similar thing for Java ME. JSR 294, an offshoot of JSR 277, is focused on the VM and language support for modularity.
Normington goes on to address the question many have had about these specifications, why not adopt OSGi rather than creating someting new. He maintains that locking JSR 277 into a version of OSGi would prevent upgrading to a new version of OSGi before the next major release of Java.
OSGi is rapidly spreading into new areas of application which are bound to result in additional requirements for OSGi R5 and beyond. To lock a particular Java SE version, such as Java 7, to a particular version of OSGi would be limiting as there wouldn't be an opportunity to upgrade the OSGi support significantly before Java 8. For example, an application that required some new features of OSGi wouldn't necessarily want to limit its deployment to Java 8 environments. So the ability to mix and match Java and OSGi versions as required is essential.
Neil Bartlett has picked up on Normington's post and feels that it rests on some dubious assumptions.
After all, OSGi works! And (give or take a few bugs in Sun’s JVMs) it has not required any enhancements to the ClassLoaders. So what enhancements are the Expert Groups for 277 and 294 looking to put into ClassLoader, and why are they necessary? This seems especially odd since 277 is substantially less ambitious than OSGi - it is a static modularity system, whereas OSGi is fully dynamic. Unfortunately I suspect he won’t be able to answer this question because of the shroud of confidentiality surrounding JSR 277.
Bartlett goes on to note that once any technology is put into the JVM the ability to upgrade it is restricted. He points out how the XML APIs based on Xerces were put into Java 1.4 or how heavily JPA was based on the rapidly evolving Hibernate 3 project.
Normington responds to Bartlett's point about the need for something more than custom classloaders by pointing out the extra level of enforcement that the JVM can bring. JSR 294 will prevent class loaders from retrieving unexported Class instances. This opens the door for extra security in the VM by securing code from inappropriate access as well as the potential for some performance optimisations.
I think OSGI is a great idea but I don't see why it has to be in the JVM. Why can't be it standardized (and it already is) and made available independantly of the JVM, what value does coupling it to a JVM level really offer? It's better to simply be able to use it rather than be forced on to a specific JVM.
Doug Leas concurrent stuff is another example where coupling to a JVM level isn't an advantage and to his credit, Doug makes versions available for older JVM levels but they use a different set of packages unfortunately.
Re: Thin arguments
"I don't think we should be coupling features to JVM levels"
One of the other reasons for JSR277 (not mentioned by Glyn)
is that because the module system is a central part of the JDK,
the JDK itself can be modularised.
Of course, this depends upon the JDK provider actually
creating the modules so you can take it "a la carte"
and swap in/out your own versions/implementations of the
Adrian Brock (Redhat)
also a member of JSR277.