The last part of this past weekend’s Classpath/OpenJDK DevJam at FOSDEM 2007 was devoted to a discussion of Java-on-Linux packaging issues led by Tom Fitzsimmons, Matthias Klose, and Tom Marble.

Each of the various families of Linux distributions has its own scheme for managing Java libraries and applications with its native package manager, be it Red Hat’s RPM, Debian’s APT, or Gentoo’s Portage. We explored ways to package OpenJDK on these distributions so as to be as uniform as possible while also respecting the differences inherent in each distribution’s conventions and tools.

More interestingly, we talked about how these packaging systems might interact with the Java module system being developed for JSR 277. At a high level it appears that there’s no conflict here, and in fact the right answer is that the Linux packaging systems should be able to leverage the Java module system rather than compete with it.

Why is this so? Well, if you think of a Java module as being analogous to a Unix shared-library object (.so) then the Java module system is just another kind of repository (like /usr/lib) with a tool (like /bin/install, or libtool) for managing the contents of that repository. The existing Linux packaging systems can already handle shared libraries, so there’s no (obvious) reason why they won’t also be able to handle Java modules.

A key new insight we had is that it would be useful for JSR 277 to support a notion of source modules, just as the various Linux packaging systems support source packages. This would allow Linux source packages to install Java source code in a standard way so that development tools that require source code (e.g., IDEs, debuggers, and profilers) could locate that code in a standard way rather than by groveling through the filesystem or asking the user.