Modularity - the next generation of programming

One of the issues that the industry has been wrestling with for quite a while has been integration. Application servers are big and integrate lots of code to provide the right set of functionality. Applications are growing in size and are integrating third party code to do the same thing. Sometimes there are conflicts. The application server may have integrated one version of Apache Commons Logging and the application needs another because the third party code they need to use requires it. This can even happen within the application itself.

The only way we're going solve this kind of problem is to remove the hierarchical classloader structure in Java and replace it with a managed classloader tree that allows versioning and control resolving dependencies. In other words, we desperately need a modular programming model.

The Java EE platform has known about this issue for some time (since before Java EE 6). It was not addressed in EE 6, but was supposed to be part of the EE 7 discussion. However, as of this month, the Java EE 7 Expert Group has dropped the ball once again on delivering modularity, citing a need for modularity in Java SE first.

However, do not despair. It's extremely unfortunate that EE 7 is not addressing industry concerns, but vendors are providing modular support today in most every app server and OSGi seems to be the predominant form. WebSphere Application Server V8.0 supports building and deploying modular apps and the WebSphere Application Server V8.5 Alpha has a Liberty Profile that shows just how much modular programming is going to change how we program. Think about WebSphere, but with roughly the size and startup speed of Tomcat and an even simpler config model than Tomcat. Best of all, it's OSGi based and gives you the control to resolve dependencies the way you want.

If you want to learn more, see http://www.ibm.com/wasdev and if you want to voice your displeasure in not addressing modular applications in Java EE 7, then send email to the spec leads (found at http://jcp.org/en/egc/view?id=342) or the public comment mailing list, users@javaee-spec.java.net.