robilad (![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small} robilad) wrote,@ 2009-06-15 17:05:00 |
|
JavaOne Roundup : Jigsaw Falling Into Place
This JavaOne was a bit different from last year's. In terms of sessions at JavaOne, I've only had a relaxed and interesting OpenJDK Porters BoF to host with my co-host, David Herron, so I could instead of hacking away on slides spend my weeks leading up to JavaOne on preparing the OpenJDK pod in the exhibition space, and happily hacking away on jpkg, a small, easy to use packaging tool for Jigsaw modules. Jigsaw is a nice code base to work with, pretty consistent, tight and clear, so after reading the code, and the corresponding documentation, writing the first iteration of jpkg with support for Debian package creation was a breeze.
Separating the architectural concept of modules in the language in JDK 7 via JSR 294 from an actual implementation provides a lot of interesting optimization opportunities at deployment time. The level of granularity at which the developer operates, and defines his or her dependencies in the module-info.java file, can be decoupled from the level of granularity at which the deployment takes place, without having to give up the module abstractions in the process. As shown in the keynote, at deployment time, the base package of the JDK can be a few kilobytes, depending internally on a couple of other, automatically created, small packages that get pulled in at deployment time as necessary using the operating system's built-in software deployment mechanisms.
The separation of concerns between the language concept of modules and the concrete module system allows using tools like jpkg to create an N:M mapping of abstract modules to concrete deployment artifacts. The freedom to pick the best delivery mechanism for a given platform is an obvious benefit, for example - on platforms with a package manager the most user-friendly way to deliver the JDK is via corresponding packages. Going native through ahead-of-time compilation, where platforms demand it, becomes possible, too, without breaking out in sweat - it turns into just another post-processing step that could be applied to modules before they are wrapped into deployment artifacts, like pack200 and LZMA compression was in the current jpkg code. Splitting a module transparently into a couple of native deployment artifacts becomes easily feasible, as well - JNI libraries, for example, can be turned into separate, architecture-specific packages, reducing the download size for complex applications with native code for several architectures (incidentally that's just like the JDK), as well as making it a bit easier to deliver just a tiny updated package for the native library portion in case of a good old buffer overflow in the native code.
In the JavaOne technical keynote (watch the video of the JDK 7 part here), Mark Reinhold made a great point about module integration in the compiler and the runtime allowing the concept of a manually managed $CLASSPATH to be retired both at compile time, and at deployment time - i.e. the $CLASSPATH is dead. Once one succeeds in making the $CLASSPATH disappear, it turns out that a lot of other things become easy - like generating out-of-the-box native launchers for Java applications, as shown in the keynote. Similarly, for applications depending on the swing or awt JDK 7 modules, one could have jpkg automatically generate the right bits in place in the generated debian packages to make the installed applications appear in the desktop menus.
Since I spent most of time at JavaOne at the OpenJDK pod talking with curious visitors and chatting about JDK 7 and OpenJDK, I missed most of the regular sessions, and went for the BoFs instead. I enjoyed Joe Darcy's Small Language Changes session (slides), but missed John Rose's cool DaVinci VM talks (slides, and more slides), and Alan Bateman's new NIO talks (slides). Like every JavaOne, there were plenty of interesting BoF sessions to pick from, my favorites being the Caciocavallo BoF (slides), given that it's another OpenJDK Porters Group sponsored project, and Mark Reinhold's and Alex Buckley's laid back Modular Java Platform Q&A session.
There was a lot of good feedback in the Q&A session, and I was pleased to see some good feedback on the web too. But that's material for another post.
This JavaOne was a bit different from last year's. In terms of sessions at JavaOne, I've only had a relaxed and interesting OpenJDK Porters BoF to host with my co-host, David Herron, so I could instead of hacking away on slides spend my weeks leading up to JavaOne on preparing the OpenJDK pod in the exhibition space, and happily hacking away on jpkg, a small, easy to use packaging tool for Jigsaw modules. Jigsaw is a nice code base to work with, pretty consistent, tight and clear, so after reading the code, and the corresponding documentation, writing the first iteration of jpkg with support for Debian package creation was a breeze.
Separating the architectural concept of modules in the language in JDK 7 via JSR 294 from an actual implementation provides a lot of interesting optimization opportunities at deployment time. The level of granularity at which the developer operates, and defines his or her dependencies in the module-info.java file, can be decoupled from the level of granularity at which the deployment takes place, without having to give up the module abstractions in the process. As shown in the keynote, at deployment time, the base package of the JDK can be a few kilobytes, depending internally on a couple of other, automatically created, small packages that get pulled in at deployment time as necessary using the operating system's built-in software deployment mechanisms.
The separation of concerns between the language concept of modules and the concrete module system allows using tools like jpkg to create an N:M mapping of abstract modules to concrete deployment artifacts. The freedom to pick the best delivery mechanism for a given platform is an obvious benefit, for example - on platforms with a package manager the most user-friendly way to deliver the JDK is via corresponding packages. Going native through ahead-of-time compilation, where platforms demand it, becomes possible, too, without breaking out in sweat - it turns into just another post-processing step that could be applied to modules before they are wrapped into deployment artifacts, like pack200 and LZMA compression was in the current jpkg code. Splitting a module transparently into a couple of native deployment artifacts becomes easily feasible, as well - JNI libraries, for example, can be turned into separate, architecture-specific packages, reducing the download size for complex applications with native code for several architectures (incidentally that's just like the JDK), as well as making it a bit easier to deliver just a tiny updated package for the native library portion in case of a good old buffer overflow in the native code.
In the JavaOne technical keynote (watch the video of the JDK 7 part here), Mark Reinhold made a great point about module integration in the compiler and the runtime allowing the concept of a manually managed $CLASSPATH to be retired both at compile time, and at deployment time - i.e. the $CLASSPATH is dead. Once one succeeds in making the $CLASSPATH disappear, it turns out that a lot of other things become easy - like generating out-of-the-box native launchers for Java applications, as shown in the keynote. Similarly, for applications depending on the swing or awt JDK 7 modules, one could have jpkg automatically generate the right bits in place in the generated debian packages to make the installed applications appear in the desktop menus.
Since I spent most of time at JavaOne at the OpenJDK pod talking with curious visitors and chatting about JDK 7 and OpenJDK, I missed most of the regular sessions, and went for the BoFs instead. I enjoyed Joe Darcy's Small Language Changes session (slides), but missed John Rose's cool DaVinci VM talks (slides, and more slides), and Alan Bateman's new NIO talks (slides). Like every JavaOne, there were plenty of interesting BoF sessions to pick from, my favorites being the Caciocavallo BoF (slides), given that it's another OpenJDK Porters Group sponsored project, and Mark Reinhold's and Alex Buckley's laid back Modular Java Platform Q&A session.
There was a lot of good feedback in the Q&A session, and I was pleased to see some good feedback on the web too. But that's material for another post.
