Does this Java EE application platform make my app look fat?

It's time to stop perpetuating the myth that all Java Enterprise Edition (EE) application platforms are a bloated mess. Overweight, over-engineered, slow performing platforms that are a burden to simply deploy Java EE applications on. There. I said it. Now can I prove the myth is unfounded? Let's see.

First let's agree on what a Java EE application platform is. I propose a minimalist definition. That being, a Java EE application platform is verified to have implemented a specific Java EE specification. The current Java EE 7 specification is extensive and runs 290 pages long. Implementing the details is no trivial task. As of the date of this article, there are eight products that have been verified by Oracle to be Java EE 7 full platform compatible implementations. Red Hat JBoss EAP 7 is one of those products. However, Apache Tomcat and Pivotal tcServer are not on the list. Neither of those products are Java EE application platforms.

Next, consider that the Java EE specification only dictates what must be implemented. Not how to implement the specification. Therein lies the source of significant differences between Java EE application platforms. There is no requirement for Java EE application platform providers to implement or share common code. While there is some common use of popular open source projects across different vendors, there are still large code differences between products. For example, JBoss EAP is a completely different code base from what is found in the Oracle and IBM products. The difference in code is going to result in many differences, including performance and memory usage, that can be discovered when comparing the platforms.

Executing and publishing performance comparisons between vendors can be a difficult task. And not just from a technical perspective. Both IBM and Oracle have terms and conditions in their respective license agreements that make it reasonably impossible for anyone to publish benchmarks run using their products. However, there are no restrictions on IBM or Oracle customers who want to run independent performance benchmarks using their own code.

Ultimately, how big or small the memory footprint of an application platform instance is will vary based on the applications deployed, the number of application instances, and the shared core services being used. When a Java EE application platform starts, it runs based on a configuration specifying what features are available and how they configured to run. So a valid question is how and when are features loaded into the server runtime and thereby start consuming memory and compute resources.

Lets take a look at JBoss Enterprise Application Platform (EAP)

The specific configuration units for features in JBoss EAP are extensions and subsystems. A subsystem provides configuration options for a particular extension that extends the core functionality of the server. Extensions are loaded as they are needed by deployments, and are unloaded when they are no longer needed. JBoss EAP ships with 38 predefined subsystems, and users can create custom subsystems if needed. Groupings of subsystems are defined in profiles to define what subsystems are available for loading and use for a server runtime.

JBoss EAP users can use pre-defined profiles, or can create custom profiles to include only the subsystems needed for a known deployment. However, in most cases this is unnecessary as JBoss EAP dynamically loads subsystems only as they are needed. Therefore, if the server or an application never uses a subsystem, it will not be loaded.

Lets take a closer look at running JBoss EAP out of the box. The default script to start JBoss EAP as a standalone sever is configured to allocate a potentially production capable gigabyte of memory for the Java virtual machine. However, JBoss EAP needs far less than that to run. In fact, after the server starts up—in less than 5 seconds—if you force a garbage collection, the memory used will be about 40-60 megabytes. Applying some basic load on the server using Apache JMeter raises the memory usage to only 200-400MB. Still, a fairly small footprint. Small enough to even run on a device like the Rhaspberry Pi.

Regardless of where you run JBoss EAP, how you should configure the Java virtual machine memory settings to handle application load will vary. However, the amount of memory required by EAP is minimal. In fact, the minimal memory used by JBoss EAP is roughly the same for running JBoss Web Server (Tomcat) or even a basic SpringBoot application deployed as a fat jar.

How does Oracle WebLogic compare?

Oracle WebLogic Server Enterprise Edition loads all classes into memory regardless of if the application is using them or not. The first time this is run the process of scanning for needed classes and establishing classloader hierarchies takes longer time than subsequent restarts where classes stored in a cache are loaded in bulk. However, in all cases, all the classes needed by the application are loaded into memory. The more classes needed, the more memory taken. Take the total amount of memory needed for a single instance and multiply that by the total number of instances, plus an amount of server administrative overhead, and you can get an idea for the total memory used by an application running on the WebLogic server.

What about IBM?

With IBM you need to distinguish between the traditional WebSphere Application Server product line and the newer WebSphere Liberty product line that was introduced in 2012.

The traditional WebSphere Application Server product line has developed a reputation for being slow and resource intensive. I believe this reputation can be traced in no small part to the generally fixed set of application services that load and initialize on startup. This includes the full Java EE platform and leaves only a few configurable extensions that can impact the memory footprint. However, as a result WebSphere Application Server does have the full programming Java EE model loaded and available by default. The downside is that all services, applications and resources are fully initialized and consuming compute resources when server startup completes.

WebSphere Liberty products are promoted by IBM as a lighter-weight and more flexible Java EE application platform option. Liberty by default starts up with a small kernel of enabled features. In fact, the default configuration offers little more than a servlet container. User configuration specifies what additional modules should be made available to the runtime. Users must know what features they need and build up a configuration to meet those needs. Initialization of configured services, applications and resources is generally delayed until they are used, in a “late-and-lazy” model. This is similar to how JBoss EAP starts and helps reduce server start times and manage the memory footprint. However, with JBoss EAP, you can avoid having to know all the Java EE features that will be needed in order to configure the server.

What’s ahead for Java EE light runtimes?

The future of lightweight Java EE containers promises to continually get better. There are two major initiatives Red Hat is involved with. First, Red Hat is a member of the MicroProfile community along with Payara, Tomitribe, IBM, and the London Java Community. The MicroProfile community goal is to provide a baseline platform definition that optimizes Enterprise Java for a microservices architecture and delivers application portability across multiple MicroProfile runtimes. The Java technology scope for this implementation is an initially planned baseline of JAX-RS + CDI + JSON-P.

Red Hat plans to offer a product in the future based on the JBoss WildFly Swarm community project with MicroProfile compatibility. WildFly Swarm offers an innovative approach to packaging and running Java EE applications by packaging them with just enough of the server runtime to "java -jar" an application. The concept of building just what is needed into a single fat jar is different from the current JBoss EAP runtime approach where subsystems are available and only loaded when needed. The WildFly Swarm approach results in a smaller solution distribution. And of course, the memory footprint of the runtime will only consume the resources needed by the deployed application.

What to take away

It is easy to find people who have heard that Java EE application platforms are resource intensive. Some of those people may have developed that opinion as a result of using the Oracle and IBM products mentioned earlier in the article. However, all is not lost.

Not everyone has dug into the details of modern Java EE application platforms like JBoss EAP. They are unaware that JBoss EAP is designed to be lightweight and efficient. They may be further unaware that Red Hat is researching and implementing technologies, and participating in open source efforts to make Java EE even more efficient. Namely, the MicroProfile community and WildFly Swarm project.

So will you go out and tell the story about how JBoss EAP is an example of how Java EE application platforms can be resource efficient? Will you help debunk the myth that all Java EE application platforms are a bloated mess? I hope you will take up the challenge.