BT

Your opinion matters! Please fill in the InfoQ Survey!

Update on Java Modules

| by Rob Thornton Follow 0 Followers on Mar 14, 2007. Estimated reading time: 2 minutes |

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

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.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Thin arguments 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.

Re: Thin arguments 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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT