BootstrappingEquinox

From APIDesign

Those of you who watch my experiments with OSGi, know that I tweaked Equinox to create the fastest OSGi container - Netbinox. Things are looking good and Netbinox will work smoothly with NetBeans 6.9. There is however one issue which revealed surprising truth: Equinox is not ready for modular environment! Unless you combine it with additional NetbinoxHooks.

The full story is available in the issue itself, but to make the long story short, here is a summary: The Equinox offers hooks for various extensions. For example one can weave the loaded classes via AspectJ. However (in spite OSGi being designed in modular way - e.g. everything loaded by separate class loaders), Equinox does not seem to be able to load the hook classes from other ClassLoader than own! The problem seems to be in HookRegistry.java:

private void loadConfigurators(ArrayList configurators, ArrayList errors) {
  for (Iterator iHooks = configurators.iterator();iHooks.hasNext();) {
    String hookName = (String) iHooks.next();
    Class clazz = Class.forName(hookName);

The use of Class.forName is the main blocker. It means only classes directly visible by the equinox.jar are accessible. This is not really suitable for modular system and implies that you basically need to load equinox.jar and AspectJ weaving JAR by the same ClassLoader.

If the above code used classical

ClassLoader l = Thread.currentThread().getContextClassLoader();
clazz = Class.forName(hookName, true, l);

then the loading succeeded even in case the AspectJ weaving code would be in its own ClassLoader just with a dependency on the ClassLoader providing equinox.jar.

Oh those boostraping problems! Some core part of the system just can't be modular! At least it might seem the code can't be modular, until somebody puts another bootstrapping code (in this case Netbinox) around your bootstrapping code (old good Equinox). Then all the modularity rules that you used to apply to libraries loaded by your framework are suddenly being applied to your framework as well.

I know the Equinox guys are well aware of the problem of adopting plain Java libraries to modular environment (I've noticed their buddy classloading policy). Such Java libraries usually assume flat classpath - e.g. they believe it is possible to load any class just by knowing its name. Only later, when somebody tries to use such libraries in a modular system, the flaws of this approach appear. The fix is as simple as shown above. But the organizational issues! Someone has to apply the patch, then everyone has to wait for new release of the broken library. To make things even worse, sometimes one gets into long and useless discussions with authors of the libraries in question. They usually don't experienced modularity yet and don't understand what is wrong with their code.

I hope that no such social issues will happen in case of Equinox. I am sure Equinox maintainers understand modularity and will be willing to fix their code soon. The only thing surprises me: how could a modular framework make such mistake and be so unsuitable for modular execution?

<comments/>