java swing extjar widgets

Integrating third party widget JARs

If you think to use third party widget libraries (instead of swing or as add-on to swing) then you should be aware if the problems about the -extdirs. The java runtime environment does only know a single extdirs actually occupied by jre-specific extensions shipped from java. There is only one such directory as it is only intended to be used by sun. It allows to update some extensions more often than the rest of the jre, e.g. the 2D-engine.

So, this may or may not be a good place to put third party modules. Remember that there might be multiple JREs in the system, from different vendors (e.g. one from sun, from blackdown, from IBM) or different releases (e.g. 1.4se, 1.4ee, 1.5beta). To get away with the "singleton" extdir you need to copy your extensions to every extdir of every JRE currently around. That makes it hard to find a good shipping format for RPM and similar binary package formats.

So many have chosen to use a non-jre directory to place java modules that can run with different jre environemts (including those from other vendors). However now there is a problem how to set the dependency on a java .class or .jar module. And suddely it gets obvious that java has not defined a sophisticated import table, not the least near to the unix shared objects or win32 DLLs. The jar system atleast allows to set some absolute depencencies.

A greater problem is about the JNI wrappers - I had been compiling a java-gnome jar that would interface to a libgtkjava.so in the usual /usr/lib system. Now imagine that but there no way to add an "rpath"-style import entry to a jar file. The manifest text is not checked for something like that. Instead, it must be set on the command line to "java -Djava.library.path=/usr/lib" to get the desired effect. And not different.

Of course there other other platform hosts which allow a lot more options in the zip manifest - but they have a different module loader that examines the entries in the zip manifest. E.g. a ".war" file does contain most the needed stuff - but that platform is different than vanilla java anyway. A common desktop installation has no way to execute .war files meant for server side extensions.

The versioning problem

While there is no library path for extension JARs (or WARs) we have even a more fundamental problem at hand - what to do about multiple versions of an extension java library. When going to specify an import in some JAR manifest then you can only choose one name for an import jar.

In fact many JAR maintainers have chosen to install a JAR under two names - one without a version number (pack.jar) and one with a version number (pack-1.4.jar). That allows an importer to specify a version-specific or module-global import. But it does not bring about anything like a functionality that can import later versions of an extension module.

That is what a unix ldso can do just easily - if the application was compiled with a dependency on 1.4 and there are two libraries 1.4.2 and 1.4.3 then we take the latter. Easy stuff. After all we are again at the saying which I've seen in a discussion board a while back: "sun has basically unsolved the dll hell problem". And despite its background in unix ldso technology. Well, that's another departement.