John O'Conner's Blog

Modularity in the Java Platform

JSR 277 is the technical spec for Java Modules, a way to promote the "module" concept in both your own applications and in the Java platform itself. In their JavaOne session this morning, the co-spec leads -- Alex Buckley and Stanley Ho -- clarified that the previous JSR 294 "superpackages" spec has been consumed by this new JSR. JSR 277 includes modularity concepts and features for both development and deployment.

In short, the goals are these:

1. promote a module concept for development
2. improve the Java platform by modularizing it
3. deliver us all from Jar hell
4. support the entire spectrum of Java programs from large enterprise apps, to applets, to desktop apps, to even "penlets" (maybe a reference to the Livescribe pen that's on sale during the conference)

Today, Java development is dominated by packages. Although package names are hierarchical, package membership is not. You can't easily share types and members across packages unless the interfaces or class members are public. That's a drag because it's clear that some classes are designed to work together even though they may be in different packages. Putting a public access modifier on members isn't always what you want in that situation, but it's all we currently have.

Modules in the JSR 277 definition would allow developers to associate classes and resources in different packages so that those classes can access each other more easily. Modules would logically gather those classes -- even if they exist in different packages -- into a common bag or module, providing the ability for those classes to work more directly with each other. In effect, you get yet another access modifier, something like module public or module private that would apply to class members across packages.

What's the impact of modules on the Java language and VM?

1. First, the word "module" would become a restricted keyword.
2. The JVM would enforce module-private accessibility
3. The class file definition would get another attribute that declares module membership.

How about developers? What's this module concept really mean for them? How do developers use it? Not much really changes in how you'll compile or run your applications:

1. Compile your package source just like you've always done: javac does the trick.
2. You'll package up or gather those classes and packages a bit differently. You'll use the "jam" tool to create JAM files. JAM files are JAva module files that resemble jar files. Think of them as an improved jar format.
3. Run your applications using java -jam SomeApp.jam. The only difference is a command line option. Oh, and the .jam extension instead of .jar.

Developers will be able to annotate classes (and modules) to describe modules versions, membership, dependencies, and other attributes. For example, you might use any of the following:

@Version
@MainClass
@Attribute
@ImportModules
@ImportModule
@ImportPolicyClass
@ModuleInitializerClass
@PlatformBinding
@ExportResources

Of course, you'll have to check out some of the technical docs and specs for more detailed descriptions of these and other annotations. But the info is out there. See the end of this blog for more information about resources you can use to learn more.

JAM files and modules should help deliver you from so-called "JAR hell." JAR hell basically refers to the confusion that developers and applications struggle with when deciding which versions of jar files to use. Yes, jar files can have version numbers, and they usually do. But jar dependencies are difficult to specify, determine, and enforce. And without classloader tricks, you can't use two versions of a JAR file...maybe a new version in one part of your application and an older version in another. Think that's an unreasonable expectation? It's not. Consider the situation you're in with XML parsers, for example. Your app might need one version. But maybe that same app uses a third party library that uses an older version of that same XML parser. Resolving this can be frustrating.

The new spec resolves some of this. Different classloaders handle each JAM. The modules system makes sure that:

1. JAM definitions and modules resolve properly against other JAM modules with similar names and APIs
2. JAM instances have their own class loader

The JAM specification is still in draft status. The co-spec leads say that the final spec will be available "soon," and I assume that means that implementations are not far behind.

To learn more:

• Attend the upcoming BOF-5032 on Wed night at 8:30 pm
• Take a look at the JSR 277 specification site.
• Check out Stanley Ho's blog, where he writes about Java modules frequently
• OSGi involvment

Comments

• Great and all. I'll skip the OSGi subject for now and just nitpick on this: When oh when will they make a different extension for executables vs. libraries. (As in 'exe' vs. 'dll'.) JNLP does _not_ make this need go away. Thanks.

  Posted by: tompalmer on May 07, 2008 at 02:30 PM

• But to look on the bright side, if jams really work around the multiple-version thing well enough, then in another five years or so, it will be nice to take for granted that this just works. And thanks for the quick review here.

  Posted by: tompalmer on May 07, 2008 at 03:19 PM

• Just curious...Would Google's Guice help in this context?

  Posted by: ebresie on May 08, 2008 at 12:14 PM

This work is licensed under a Creative Commons License.