Finding the right mix of Java EE functionality

Despite Java EE having a clear functional advantage of Java SE, some developers feel that Java EE is too feature rich. They prefer to build up the functionality of Java SE by progressively adding jar files to the classpath. When this approach is taken, compatibility testing of the mixed jar file additions can fall on the developer along with any associated required debugging and problem resolution —  all tasks that distract the developer from the job of developing solutions and,  arguably, tasks that an application platform vendor like Red Hat is better able to take on.

Users of a certified Java EE application platform like JBoss EAP often find that either the web profile or full platform capabilities defined in the Java EE specification are sufficient for an application platform runtime profile. However, some users want the flexibility to optimize the runtime profile to optimize computing resource usage. Essentially, they want to tune the application platform to provide only the Java EE capabilities needed.

JBoss EAP functionality includes a modular class loading system for controlling the class paths of deployed applications. Developers have fine-grained control of the classes available to their applications and can configure a deployment to ignore classes provided by the application server in favor of their own. For example, some existing applications may use Hibernate 3 instead of 4, or log4j instead of JBoss logging. Flexibility plus isolation is the key value for both developers and administrators. In addition, dynamic modules are only loaded when required which contributes to faster platform startup times.

Looking at the upstream JBoss EAP community projects, WildFly Swarm is the project that bundles an application with just enough of the application server into a single runnable jar file for microservice-style applications. This is a new and emerging possible additional refinement to class modularity being innovated by the opens source community. The declarative  approach of WildFly Swarm to define only what libraries are needed for an application to run is not currently included with JBoss EAP 7 but may be considered for future releases.

Pivotal and Spring as a Java EE alternative

Pivotal does not offer an application platform for developers to directly use Java EE. This is a critical point for evaluators to understand as it can potentially eliminate Pivotal from consideration as a Java application platform.

Pivotal offers Java developers the Spring framework as an alternative to a certified Java EE application platform. The Spring framework allows developers to use simple Java objects that can in turn leverage Java EE features. The Spring framework’s popularity grew during the period that J2EE 1.4 was the latest specification version and considered difficult to use. Java EE 5 through Java EE 7 were heavily influenced by the popularity of the Spring framework and a need to simplify use of Java EE, and in return, the Spring framework was heavily influenced by Java EE’s convention over configuration approach and use of annotations.

Today, with Java EE 7 application platforms like JBoss EAP available, there are multiple articles that debate if the Spring framework is still needed. The core argument for this is that the Java EE specification has benefited from the lessons learned from the Spring framework and that the need for Spring has run its course.

Pivotal would of course argue this is not the case and indeed the Spring framework and the many sub-projects within it are still relevant for Java application development. Most notably, this is useful when creating 12-factor applications (microservices) for cloud deployment — a design philosophy that precludes using many Java EE features and a Java EE platform because they can argued to conflict with 12-factor application principles

The belief that 12-factor applications mean the demise and abandonment of Java EE represents a distinct difference between Red Hat and Pivotal. While Red Hat continues to fully embrace and support the Java EE standard, it also supports using new application design approaches such as microservices and 12-factor applications.

Two different platforms through IBM

IBM offers two distinct classes of products for Java EE development. First, is the traditional WebSphere Application Server, the product that IBM recommends for legacy applications with heavy backwards compatibility requirements. The WebSphere Application Server has a long history that includes a reputation for not being modular. As a result, developers and administers have limited options to tune the size of the runtime environment.

In recent years, IBM has released the WebSphere Liberty Profile. This new Java EE application platform is positioned for new development and projects that can be migrated off the older traditional WebSphere Application Server. IBM promotes the modularity and speed of this new, but still highly proprietary, Java EE application platform offering as being competitive with JBoss EAP. Indeed both WebSphere Liberty Profile and JBoss EAP offer users good modularity features to tune the runtime. However, looking forward, the work being done in the open source community with WildFly Swarm is currently unmatched by IBM.

Oracle’s Focus on Dense Applications

Oracle WebLogic Server offers limited modularity features compared to JBoss EAP. In fact, the Oracle WebLogic Server Enterprise Edition is arguably geared towards running densely distributed, full featured Java EE applications.

The WebLogic multi-tenancy feature for version 12.2.1 supports this conclusion. This product has a sole purpose of increasing individual server density which allows for server consolidation. It is a separately licensed add-on product that enables multiple isolated tenants to run applications on the same instance.

After extensive research, Red Hat has concluded that there are very few other options for administrators to reduce the WebLogic footprint. One such option is a start-up mode called WLX which is provided and turns off EJB, JMS, and JCA containers. This leaves only the web container enabled, which can speed startup of the WebLogic server. In addition, but not a modularity feature, Oracle WebLogic offers a class caching feature for use in development which can further reduce WebLogic startup times. However, class caching is not supported for production use.

In addition, the Java EE 7 web profile contains web technologies that are part of the full platform and is designed for developers who do not need the full set of Java EE APIs to run applications. JBoss EAP is certified for both web and full profile support. Oracle WebLogic is not web profile certified. While the web profile capabilities exist in the full platform specification WebLogic Server is certified for, there is not a WebLogic startup option to run just the technologies associated with the web profile. This can lead to unneeded overhead for users that only need web profile capabilities to support deployed applications.

Comments are closed.