[JavaProblems]

Here's a problem I have had with Java dynamic loading...

In C++ I often use an idiom similar to ConstructionIsResourceAcquisition in which static objects at file-scope are used to automatically register one module with another.  They register the module in their constructor and unregister it in their destructor.  This allows a library user to extend a library without changing the code of the library or calling initialisation functions in main.

In Java, it seems at first sight that the use of static blocks would make this idiom extremely easy to implement.  However, if you do so, you can get bitten by Java's lazy dynamic loading: Java does not guarantee to load a class until one of it's methods is called.  If a class must register itself in a static block in order to be called at all, it will ''never'' get called because it will never get loaded and the static block will never get executed.

Solutions?  I guess one could use ThirdPartyBinding to explicitly set up dependencies.  This pushes responsibility onto the library user and can expose implementation details.  On the other hand, the system architecture will be obvious and so the system will be easier to maintain as a result.

Alternatively, one could use a system property to hold a list of packages that can be searched for library "plug-in" ParameterClasses.

--NatPryce.

In a previous life we bumped into this sort of problem and inevitably ended up setting up a factory object somewhere to link all the pieces together. At least with dynamic loading, you don't have to fix the implementation of the factory at link time. I had once terrible problems doing this sort of thing in C++ because the application was threaded, and I couldn't guarantee when some of the initialisation code would be called. --SteveFreeman

----

Just for the record, I would say that this is definitely ''not'' a problem with the JavaLanguage or runtime environment.  It is just an interesting problem I had to solve when porting code from C++ to Java. --NatPryce

A common question on CompLangJavaProgrammer is "i have a system with modules; how can i automatically detect what modules are available?". The usual answer is "you can't; you have to put a list of modules somewhere (eg a properties file) and then load them.", although sometimes people get adventurous and suggest that the module manager could search the classpath somehow, looking for modules. This is actually quite straightforward to do, and could easily be written up as a standard or pseudostandard class.

However, there is another way. Dig deep into the bowels of the java documentation and you will find a description of the service provider facility in JAR files:

http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Service%20Provider

Basically, this is a lightweight way for a JAR file to say "i've got a class which implements interface foo.bar.Baz", so that someone interested in looking for implementations of foo.bar.Baz can find it. The documentation implies that  there is a standard API for using this facility, but there is no sign of it in the JDK javadocs. It is possible that this is a facility for internal use by the JDK, which has somehow been documented in the public documentation. It is also possible that it was designed but never implemented. Either way, it's something that would actually be incredibly useful. It would be straightforward to implement it in a user-level class, so perhaps at some point i will.

-- TomAnderson