BootstrappingEquinox

From APIDesign

Those of you who watch my experiments with OSGi, know that I tweaked Equinox to create the fasted 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!

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 for weaving the loaded classes via AspectJ. However (in spite OSGi designed to be modular - 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 module would be in its own JAR with dependency on the module providing equinox.jar.

I understand the boostraping problems. I even know that there is buddy classloading policy - so it is clear the Equinox guys already faced problem of using plain Java libraries in modular environment.

Such Java libraries usually assume flat classloaders - 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 someone has to do it and wait for new release of the broken library. Sometimes this involves long and useless discussions with authors of the libraries in question as they usually don't understand what is wrong with their code.

I hope that nothing outlined above 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 development?

<comments/>