Have you read the announcement of the alpha release of Red Hat OpenShift Application Runtimes (RHOAR)? We also posted an introduction to the component in RHOAR earlier.

Red Hat Intends to include entitlements for the JBoss Enterprise Application Platform (EAP) as part of a Red Hat OpenShift Application Runtimes (RHOAR) subscription.  The reasoning for this is dead simple, there is still strong demand for a Java application platform the implements the Java EE specification. JBoss EAP 7 fits that requirements with certified full platform and web profile support for the Java EE 7 specification. Best of all, JBoss EAP offers Java EE 7 capabilities in a small, fast, cloud ready footprint. It has been available on the OpenShift Cloud Platform (OCP) since version 6. JBoss EAP is cloud ready and deserves to be included as a RHOAR component.

I want to believe. Prove that JBoss is small and fast!

First lets 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, JBoss Web Server, and Pivotal tcServer are not on the list. Those products are not 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 line from what is found in the Oracle and IBM products. The difference in code lines is going to result in many differences, including performance and memory usage, that can be discovered when comparing the platforms.

Ultimately, how big or small the memory footprint of an Java EE 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.?

In the case of JBoss EAP, the specific configuration unit for features is 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 nearly 40 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.

Let's take a closer look at running JBoss EAP out of the box. The default script to start JBoss EAP as a standalone server 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.

TABLE: Resource usage example running a simple REST application with runtimes using default settings. Test was run with ApacheBench using 100K request with 50 users and keep-alive enabled.

Runtime (framework) Boot time server only Boot time including app deployment Memory usage without load Memory usage under load Measure throughput
JBoss EAP (Java EE Web) 2 - 3 sec 4 - 4.5 sec 40 - 60 MB 200 - 400 MB 15K req/sec
JBoss EAP (Spring) 2 - 3 sec 9 - 12 sec 40 - 60 MB 500 - 700 MB 6.8K req/sec
JBoss WS/Tomcat (Spring) 0 - 1 sec 8 - 10 sec 40 - 60 MB 0.5 - 1.5 GB 8K req/sec
Fat JAR (Spring Boot) N/A 4 - 6 sec 30 - 50 MB 0.5 - 1.5 GB 9K req/sec


What about MicroProfile?

The future of lightweight Java EE containers promises to continually get better. There are two major initiatives Red Hat is involved with. Microprofile is one of those. Red Hat is a member of the MicroProfile community along with Payara, Tomitribe, IBM, and others. 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 the current implementation is JAX-RS + CDI + JSON-P.

RHOAR is offering support for MicroProfile via the JBoss WildFly Swarm upstream project. 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. More details on MicroProfile support i RHOAR will appear in a future blog article.

What to take away

Don’t discount the continuing need to have a Java EE application platform as part of the runtime options you want available for cloud-ready applications. Don’t be discouraged from using Java EE in the cloud based on preconceived notions that Java EE application platforms are resource intensive. Those perceptions may have developed that opinion as a result of using arguably heavy Java EE platforms such as Oracle WebLogic and IBM WebSphere products.

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 community efforts to make Java EE even more efficient. Namely, the MicroProfile community and WildFly Swarm project.

So will you go out and talk about how JBoss EAP is an example of how Java EE application platforms can be used for cloud applications? Will you resist and debunk the myth that all Java EE application platforms are resource intensive? Let us know via comment and tweets. We want to hear you #RHOAR!