10 Jul 2006 robilad   » (Master)

Java Modularity Pointers

Every now and then, there is some thread somewhere where Java developers get to exclaim their demand for interesting features. It seems that modularisation is going to be a hot topic, judging by the JCP struggle between Sun and OSGi, i.e. JSR 277 and JSR 291, and talk at the various 'community' sites.

Looking at Richard S. Hall's slides from ApacheCon Europe, which lifts some of the NDA veils that Sun keeps for whatever weird reason on JSR 277, a lot of the thinking behind the various plans seems to work towards enabling annotations of the code with various constructs, be it annotations to describe module structure, versions, or bundles. If it requires manual labor, I'm not sure if it is going to take over the world, though. See Maven, OSGI bundles, Ivy, etc. all of which are pretty nice, but require someone to do some work to take care of the metadata, and keep it all up to date, which has kept the repositories relatively small.

So, what else is out there, that tries to solve the problem more automatically?

Beside Luca Cardelli's foundational work in the area, there has been a lot of interesting work done at DISI in Genua.

In an ideal world, my compiled classes would have additional information on their dependencies for rebuilding and linkage, in form of type constraints, so that I could query a module repository's database for the set of classes that would safely link, while preserving binary compatiblity, and refine the set to only the classes fullfilling constraints on their tagged versions, binary hashes, etc. The module repository database of type information would be largely automatically compiled by extracting exported types and their linkage constraints from the class files, and allow annotating them with some manual versioning information, for additional convenience. The module repository would be able to translate module names between its own format, and my local packaging system, and detect that it doesn't have to download a class that Debian already packages in a suitable bytecode version, or as a suitable gcj-ed native DSO. It'd be able to degrade gracefuly on systems without native software packaging mechanisms. In an ideal world, the module repository would figure out which native library to load based on the native linkage symbols in the class file, without requiring an explicit System.loadLibrary() call in the Java code, and the guessing game of DSO names.

That's what I'd like to see a future Java module system do or at least make possible.

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!