The goal of this post is to discuss at a high level the radical change in the class-loading mechanism used by JBoss, and some of the benefits of this change. Since the inception of JBoss, issues around how Java classes are discovered and loaded into the server have never been fully addressed. For those of us who have faced an unexpected ‘ClassCastException;’ troubleshooting those issues has often been a mystifying experience. Especially since the class-loading strategy has changed over multiple releases of JBoss through the years. Additionally, most developers do not wish to spend their time investigating how their classes are loaded and isolated from other applications running on the server. Our focus is on getting the business logic right, in compliance with the Java EE spec.
In JBoss 7 and WildFly 8, the method for finding and loading classes has undergone revolutionary change from the previous versions of JBoss to address these issues. Gone are the Bootstrap, System and UnifiedClassLoaders; enter JBoss Modules and the ModuleClassLoader. In my opinion, this is one of the most significant developments in JBoss in years. For the sake of brevity, since both JBoss 7 and WildFly 8 include this technology, I will refer to the more recent WildFly 8 going forward.
WildFly 8 joined the industry’s steady pace toward modularized software by utilizing the JBoss Modules implementation at the lowest layer of the server architecture. In short, JBoss Modules is a “standalone implementation of a modular class loading and execution environment for Java.” The implementation is thread-safe, fast, and highly concurrent. Also, modules are also never loaded until they are required by a dependency. The fact that it is standalone means that JBoss Modules can actually be used outside of the application server, but my focus here is on the benefits of its use within the application server.
This means, from WildFly’s point of view, that everything is a module (Java EE APIs, libraries, resources, war files, ear files, etc.), and every module has its own classloader, the ModuleClassLoader. This classloader only loads the classes contained within the module definition as well as classes from modules explicitly defined as dependencies. This releases us from the previous hierarchal class-loading mechanism where application server classes could potentially “clash” with those included within an application, resulting in the dreaded “ClassCastException” mentioned earlier. We finally get true class loading isolation.
Another advantage JBoss Modules brings is that modules are loaded concurrently instead of sequentially, as with the old, hierarchical class-loading mechanism. This gives WildFly the ability to take advantage of today’s modern multi-core processor architectures to load all of the classes it needs to run at once, in a fraction of the time it took previously. This supports the project’s claim of “blazing fast start up” speed.
Finally, since JBoss Modules only loads explicit dependencies at the time they are needed, it allows the server to run with a much smaller memory footprint than its predecessors.
These points discuss briefly some of the benefits JBoss Modules brings to JBoss7/WildFly. I did not mention OSGi support, which is built upon JBoss Modules, and is a modularization standard for Java. That may be a topic for a future blog post. However, I believe the reasons above are enough to justify some serious discussion within your organization on moving to JBoss 7/WildFly to take advantage of these benefits.