Skip to main content

Keep 'Em Separated

Posted by editor on October 19, 2006 at 8:51 AM PDT

Will the JAM bring order to JAR chaos?

So, back at JavaOne 2005 -- yes, "5", not "6" -- I think the single thing in the keynote roadmap that interested me the most was a short bit of what almost seemed like thinking aloud about the limitations of the JAR file as a distribution format. The reality, particularly for desktop devleopment, is that JAR versioning is haphazard or nonexistent, so developers tend to bundle the specific versions of the libraries they need and use classpath trickery (or OS-specific configurations) to ensure that the right versions of the right libraries get loaded. And even this isn't foolproof -- ask me about the time another team at a former employer put a year-old version of one of my team's JARs in the lib/ext folder.

So, it's fascinating to see that an Early Draft Review is now available for JSR 277 - Java Module System, which aims to rein in all of this nonsense and create a JVM-supported mechanism for deploying Java applications and expressing their dependencies, versioning, what they export for other applications to use, etc. The draft is big -- 87 pages for the main body of the proposal, plus another 75 of appendicies and related documents -- so it's too much to summarize in this space (surely some other bloggers will be posting their opinions and ideas). The central deployment story (there's a separate development module story) is that a JAM file (meaning "JAva Module") will be the basis of future deployment, and that it will contain a metadata file much like the current manifest file, describing its unique name, version, dependencies on other modules, exported classes (ie, what it makes visible to other modules, etc.).

A brief note in section 1.6 points out that the module format is designed to be language-agnostic. This might make the JAM broadly useful for all end-users -- JVM-based versioning and deployment of any language on any operating system could make the JVM an absolute must-have for all users, which would eliminate Java's worst deployment problem today: getting a JVM installed for users who don't already have one. As an aside, this is one thing that Bruce Tate got very right in Beyond Java: by solving difficult problems of security and cross-platform execution, the JVM has become so valuable that any would-be successor to Java would have to run on it.

There are probably some compelling server-side uses for JSR-277 too. Surely you know of companies where the developers count on Joe (or Jill) in IT to put the right JARs and the right scripts in the right places on the deployment servers. So what happens when when Joe or Jill is gone in the next mass-layoff? A works-the-same-everywhere deployment scheme has a lot of appeal here.

Anyways, if the topic interests you, check out the draft. The draft review period runs through November 13, and a vigorous discussion can only help improve the spec.

Also in Java Today,

the new Glyph project aims to provide a set of utilities and annotations to speed up development for Jini-enabled applications. "J2SE5.0 annotations are used for automatic service creation and creation of smart proxies for remote objects, and generation of associated Jini configuration files. A number of utilities have been written to help manage exported objects, and ease service initialization. In development, there are other helpful classes such as service filters, and Pack200 URL handlers that can significantly reduce the size of a downloaded jar file when working with mobile code." The project already has downloads and a tutorial.

The JOGL-Demos project contains Java demonstrations utilizing OpenGL through the JOGL API. They exhibit advanced functionality such as vertex and fragment programs, shadow maps and hardware-accelerated offscreen rendering via pbuffers. Most of the demos were ported from C or C++, in which case a link to the original sources is provided. Check out the project's home page for Java Web Start versions of each demo.

Today's Feature Article looks at

Invoking Assembly Language Programs from Java.
After all, nearly everything written about Java Native Interface (JNI) assumes that your native code will be written in C or an offshoot like C++ or Objective-C. But this isn't the only option. For high performance and close-to-the-metal coding, you can call assembly language from JNI. Biswajit Sarkar shows how to do it.

Today's Weblogs kick off with a look at What's New for JavaOne in 2007, in which Annette