Welcome to JSR-277!

Although I’ve known for a bit, I couldn’t say anything until now, when I just received the official welcoming letter: I’m a part of the JSR-277 Expert Group, the so-called “Java Module System” JSR. Although you can read the full spiel on the JCP website, the nuts-and-bolts part of this story is simple: we (or at least, I) want to fix the horribly busted component model in Java. Or, rather, the lack of any such thing, beyond what the J2EE world offers (which isn’t much).

To put it into EG Lead Stanley Ho’s words from the JSR-277 home page,

The specification of the Java Module System should define an infrastructure that addresses the above issues. Its components are likely to include:
  1. A distribution format (i.e., a Java module) and its metadata as a unit of delivery for packaging collections of Java code and related resources. The metadata would contain information about a module, the resources within the module, and its dependencies upon other modules. The metadata would also include an export list to restrict resources from being exposed outside the module unintentionally. The metadata may allow subset of exposed resources to be used by other modules selectively.
  2. A versioning scheme that defines how a module declares its own version as well its versioned dependencies upon other modules.
  3. A repository for storing and retrieving modules on the machine with versioning and namespaces isolation support.
  4. Runtime support in the application launcher and class loaders for the discovery, loading, and integrity checking of modules.
  5. A set of support tools, including packaging tools as well as repository tools to support module installation and removal.
We also expect the Java Module System to expose the public J2SE APIs as a virtual module in order to prevent unwanted usage of the private APIs in the implementation.
In other words, a lot I’ve long railed about being broken in the Java runtime. About the only thing I wish we could do that’s out-of-scope to the JSR is to fix the javac compiler to cease emitting .class files directly, but instead consider .class files to be the moral equivalent of C/C++-compiled .obj files, and automagically do that final step and turn it into a .jar file right out of the box. (Out of curiosity, is there anybody out there who doesn’t immediately jar up your .class files?)

There’s some high-powered folks on this JSR, as there was on my last EG, such as Stu Halloway, David Bock, Doug Lea, Sam Pullara and Hani Suleiman (gotta be careful about emails to Hani, though, or I might find myself the subject of a weblog entry and I dunno if my fragile ego could handle that…). I’m looking forward to working on a JSR with Stu, with whom I’ve not closely worked since Stu left DevelopMentor to go his own path, particularly since I’ve been… err… disagreeable, shall we say?… with his business partner. Not only that, Stu appears to have taken a deep hit of the dynamically-typed languages Kool-Ade, and I always welcome reasoned debate with somebody who’s perspective wildly differs from mine.

Once again, I think my major contribution will be the experience of the .NET world, and their experiences with assemblies. It will be particularly interesting to see how Java Modules will or won’t closely emulate assemblies, and to be 100% honest with you I’m not sure if it would be a Good Thing or not if they did. I think there’s definitely some goodness to how assemblies work, but there’s also some interesting feedback filtering through the collective .NET unconscious that seems to disagree with my own perceptions.

All in all, it’s going to be an interesting ride. Wish us luck–this is probably one of the more influential JSRs in the JCP for Dolphin, as it’ll change the packaging and deployment models for both J2SE and J2EE (and beyond), so if we screw this up…. shudder

BTW, if you know of a good component model beyond Eclipse, NetBeans, .NET or OSGi, please drop me email and tell me why you think it’s something I should look into. I won’t promise anything, but obviously the more experience we can draw upon, the better the chance we have of the final results not… well, not sucking.