Modularity and the Java platform

Neil questioned the point of putting modularity support into the Java platform.

Of course, OSGi does a pretty good job of modularity support based on java.lang.ClassLoader. So why isn't that sufficient?

At one level, OSGi is quite sufficient. There is already massive adoption of OSGi and this is continuing to spread into new and interesting areas.

At a more theoretical level, there are some things that custom class loader networks will never achieve.

Most importantly is VM enforcement of module boundaries. It is possible to obtain unexported Class instances from a class loader. OSGi bundles are implemented as class loaders. Similarly, JSR 277 modules will boil down to specialised class loaders. So this is where JSR 294 comes in with its objective of enforcing module boundaries in the VM.

This extra level of enforcement is irrelevant if the aim of using modules is to divide a piece of software into manageable units with well-defined interfaces.

However, VM enforcement starts to become interesting if modules need to protect some parts of an application or the system from inappropriate access. There is also some scope for additional, or at least simplified, performance optimisations if certain classes can be guaranteed never to be accessed outside their defining module.

I would dearly like JSR 294 to provide mechanisms that will be equally useful to OSGi as to JSR 277. I think OSGi would benefit from VM support, although it would be an exaggeration to say that OSGi really needs VM support.