Update on Java Modules

Posted by Rob Thornton on Mar 14, 2007 08:00 AM

Community

Java

Topics

JCP Standards

Tags

JSR 277,

JSR 291,

JSR 294

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.

1. Back to top

   Thin arguments

   Mar 19, 2007 8:08 AM by Billy Newport

   This hasn't stopped JSRs putting specific function is specific J2SE levels. All the new APIs are ALWAYS only available in a newer JVM isolating customers on older JVM levels. I don't think we should be coupling features to JVM levels, I'd prefer to see features being available seperately and able to run on ANY JVM including older ones. This philosophy is whats driving me to making ObjectGrid from WebSphere XD available on older JVMs and WebSphere versions as well as competitive servers. 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.

   Reply

2. Back to top

   Re: Thin arguments

   Mar 21, 2007 12:28 PM by Adrian Brock

   Billy Newport wrote: "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 components. Adrian Brock (Redhat) also a member of JSR277.

   Reply

• Older >