7 Reasons to love JBoss AS7 - Part 4
3) Core Modularity
Mark Reinhold, Chief Architect of the Java Platform Group at Oracle, famously stated at JavaOne 2009: “The classpath is dead.” Experience has taught us that hierarchical classloaders are problematic, often causing failed deployments and quirky behavior. They are the equivalent of a waterfall, where server implementation classes pour into the application’s classpath below. There’s no question the future of Java is a modular one. The time has come to say goodbye to the parent delegation model and find the path to modularity (i.e. sane class-loading). But first-class modularity in the JVM still remains on the horizon (planned for Java 8, a year away at least). Is it possible to build a modular server before then?
One way to achieve modularity is to build the server on top of OSGi, which offers both a module system and service platform. In fact, at least one Java EE implementation has taken this approach, GlassFish 3. In contrast, the Application Server 7 team believed, with minimal effort, they could intro- duce a solid, usable modularity standard that’s not burdened with the overhead and complexity of OSGi. They proved it with JBoss Modules.
A module system provides a way to package up classes and resources into modules, and establish a graph, at runtime, of classloaders such that all the expressed dependencies are satisfied. This organization is a contrast to the traditional method of running an application using the default classpath mechanism, which produces a single application classloader with all the resources in those jars concatenated together in one big blob. In other words, jar hell. Modules can greatly alleviate this problem. When all jars are bundled as modules, a JAR will never see a conflicting version of a dependency class, or pick up resources from other jar inadvertently. Also, a module which is never used will never be loaded which can improve startup time of large applications.
JBoss Modules, the core classloader in JBoss Application Server 7, provides this modular structure. As a result, it offers true application isolation, hiding server implementation classes and only loads the classes your application needs. Every application acts as a module. Modules, packaged as collections of classes, are peers that remain isolated unless explicitly defined as a dependency of another module. Visibility rules have sensible defaults, yet can be customized. The modular classloader keeps applications isolated, so you can use your own XML parser or Hibernate libraries without experiencing jar hell. Not only does JBoss Modules allow Application Server 7 to do classloading right, it’s also a key contributor to its lightning speed. It was designed for a high degree of concurrency. JBoss Modules can load only the classes you need and does so with extremely fast, O(1) resolution. In addition, classes can be loaded concurrently, making use of that multi-core processor once again. By segmenting classes into proper modules, the app server can naturally optimize access patterns, and only look in the spot that truly owns the classes. Also, since the visibility between modules is intentionally limited, searching is cheap.
From an engineering standpoint, we can say that JBoss Application Server 7 is very well designed. This follows a long tradition of JBoss Application Server being developer-friendly. But roles have changed since JBoss 3, as Java EE has been widely adopted by large organizations. That means develop- ers aren’t the only target audience. In addition to solving en- gineering challenges, the JBoss Application Server 7 team has focused on making administration elegant (to cater to managers, the more technically-oriented devops, while still giving plenty of tools to satisfy developers).