JavaOne: Jigsaw and Java Modularity

4

I started off the morning at a pair of Java modularity talks by Mark Reinhold on Jigsaw and from Alex Buckley on JSR 294. Mark’s talk was apparently a dup of the technical general session yesterday but I missed that so that was actually good for me.

Project Jigsaw aims to provide a module system for the JDK itself (also open for external users). This system provides the means for packaging and deploying applications based on modules. I found it somewhat hard to separate in this talk which parts were Jigsaw and which parts were defined by JSR 294 but Alex’s subsequent talk helped further break that down.

Modules will enable us to more quickly download (or startup) a smaller subset of the JDK than the whole thing and provide a better way for us to package, find, download, and deploy our applications.

The more I saw of this talk, the more I realize the scope here is ambitious – there is a pretty coherent vision in this demo and it’s broader reaching than I had previously understood. The vision includes a complete overhaul of how we compile, package, and startup our Java applications. In particular:

The classpath is dead.

That’s big and important, so let me say it again:

The classpath is dead.

That means that when you write your application, you break it into modules (think projects in Maven or Eclipse, etc). Each module declares it’s dependencies. When you compile the code, you compile it with a modulepath. There is no classpath – the modules define the dependencies and javac can use the module metadata and modulepath to figure that out.

Mark’s demo showed using a new jpkg tool to combine a bunch of classes to build a debian package:

	jpkg -m classes -d . -c hello deb org.hello

You would then get this into some debian repository (I don’t know anything about linux package mgrs sorry) and you can then retrieve that package through normal package managers (he was demoing with Synaptic).

There was also a new jmod tool to look at what modules are installed:

 	jmod ls

There were some very good questions at the end that pointed out some major holes that still need to be filled. In particular, it was noted that there is no standard packaging format or package management system on some relatively important OSes like Windows and Mac. :) Also, there is no platform-neutral deployment packaging format – the jpkg is building platform-specific packages and you would then need to build one for every platform you want to publish. That seems to throw a big wrench in between the “Write Once” and “Run Anywhere” steps that involves creating N packages.

But these are solvable problems. I see the vision now more than I ever have in the past – it’s compelling but it seems like a long way to go in a short time for Java 7.

I should note that if you don’t want to use modules, everything should be backwards compatible and you can continue doing what you do today.

Comments

4 Responses to “JavaOne: Jigsaw and Java Modularity”
  1. Augusto says:

    Hi Alex, you know I didn’t notice the jpkg command in the general session. Still not clear what this command would do on Windows.

    The Q&A session that night went into a lot of discussion about native deployment, but unfortunately we didn’t get to talk too much about the tools.

    I put some notes about the Q&A and other topics around this issue on my blog in case you are interested:
    http://sellmic.com/blog/2009/06/11/classpath-hell-just-froze-over/

  2. Alex says:

    @Augusto: I think from the Q&A afterwards he mentioned that they didn’t know what it would do for Windows or Mac. That was the part I mentioned at the end of the post.

  3. Chris Wash says:

    Macports will let you do package management on the Mac. Cygwin to some extent does this on Windows.

    Also, both Windows and Mac have built-in update managers which provide this capability to a certain extent, albeit may be a proprietary medium/format.

  4. Alex says:

    I’m aware of Macports but that’s not a “standard”. I suspect most consumers and even many devs may not have it installed. And I think Cygwin is even farther from a standard package manager on Windows – requiring that seems really weak to me.

    I’m not sure how well the Windows/Mac update manager map to package management either. Seems like the functionality is overlapping but the goals are definitely different.