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.
