Java EE vs Java SE: Has Oracle Given up on Enterprise Software?

Everything you need to know about Java EE and its current status

Java Enterprise Edition is one the biggest sources for confusion in the worldwide Java community. The weird thing is that even if you’re experienced with developing for EE, the complete picture is often still fuzzy. In this post, we’re taking in all recent news and taking a closer look at Java EE to clear out the fog with the help of Werner Keil from the Java EE 8 expert group, and Reza Rahman, former Oracle Java EE evangelist and founder of the Java EE guardians.

Exactly how is Java EE different from Java SE?

To kick off, we need to make an important distinction. Java EE is built on top of Java SE. Unlike Java SE, the Enterprise Edition of Java is officially “just” a specification, with actual implementations available from Oracle (like the Glassfish reference implementation) and other vendors like RedHat and IBM.

While SE’s APIs provide the standard core capabilities of the Java language (java.* packages), EE’s APIs (javax.*) provide extensions to Java that are super useful for developing large-scale applications. With that said, there can be exceptions which cause additional confusion. Swing for instance started off as an extension, and ended up as part of core Java. It’s not a bullet proof concept.

We got in touch with Java EE 8 expert group member Werner Keil for further insight. “The big misconception is whether or not APIs are a coded manifestation of the specification or rather its implementation” says Werner. “Almost every Java EE project now considers it the implementation, and a vast majority therefore have all of its code covered under increasingly open licenses. Except for the Technology Compatibility Kit (TCK) test suites where there’s still a big problem with proprietary closed TCKs only accessible to Oracle and corporate licensees.”

On a side note, these type of licensing issues eventually caused the Apache Software Foundation to withdraw its membership from the Java Community Process executive committee back in 2010.

So what does the EE spec actually include?

In practice, Java EE is an umbrella specification for enterprise Java extensions. At its core, it includes independent capabilities like Enterprise Java Beans (EJBs), the Java Servlet, Rest API (JAX-RS), Contexts and Dependency Injection (CDI), and many more.

Every new release includes upgrades to individual technologies, together with new capabilities. For example, Java EE 8 is expected to include the Servlet 4.0 spec with HTTP 2.0 support.

Since Java is backwards compatible, you can also run older EE versions on top of new SE versions and enjoy the new language features. For example, a Java EE 7 compatible implementation on top of Java SE 8 for lambdas and streams, so you don’t need to wait for the Java EE 8 to use it.

A main feature of Java EE is the Servlet spec. Currently at v3.1, with v4.0 under development. One of its most popular implementations come from TomEE, which is an EE compatible version of Tomcat.

Heavyweight Java EE is a myth

In contrary to popular belief, Java EE is much lighter than it seems. Properties like artifact size, build time, and deployment time can be pretty minimal. Lightweight is a design decision, and other frameworks who are considered to be lightweight can become… heavyweight.

“Probably the most common misconception about Java EE is that it’s too big, heavy or monolithical and not as flexible as Play!, Spring, Node.js or all the other “hip” and new or older alternatives out there. We had an entire Tomcat or Glassfish server run on a Raspberry Pi” – Werner Keil

Debugging Java EE in Production

A recurring issue for distributed production environments, and especially with microservice architectures, is understanding what’s happening in production. While not specific to EE, an issue that starts with one service can cause trouble elsewhere and then you’re left alone digging through logs, trying to find clues that might not even be there.

At  we’re taking a new approach to solve these kind of problems. Anytime an exception, log error or warning happens, we present all the needed data to get down to its root cause. This includes all the related source code and state throughout the error’s stack trace

Java EE vs. Java SE release cycle

The work on Java EE is managed under a single umbrella Java Specification Request (here’s the one for Java EE 8) and waits for SE to be completed in order to define the exact spec. We’ve summarized the release dates of all versions in the following table:

Why does it usually take 2 years for EE to be released after SE?

“I think this historically evolved over time. The first then J2EE technologies like EJB were presented in 1998 a little over 2 years after Java officially started in 1995.“ says Werner Keil. “Once a larger number of companies and contributors started to help Java EE under the JCP, enterprise technology naturally takes some time to have all the parts under the EE umbrella be ready, tested and integrated.”

Werner added, “I personally see the need for a strict binding of Java EE version X to the same JDK version X become less important even for large corporate users. Several vendors already started to bundle their latest Java EE 6 or 7 compatible products with Java SE 8 by default.”

“Once Java EE 8 is ready, we’ll hopefully see Java SE 9 and its Jigsaw modularity system not only final but also relatively mature. It may take some time for Enterprise servers to cope with this huge step, but as soon as modularity is properly understood and adopted, I see probably an even bigger benefit for EE than SE. The fairly small number of EE profiles should grow and leverage all the optionality and modularity the underlying platform can then offer.”’

What’s the Current Status of Java EE 8?

Java EE 8 is expected to be released in the first half of 2017. It seems we’re expected to experience additional delays. Werner Keil elaborates on these issues:

“Unfortunately not only due to the delays of Java SE 9, but what seems to be a strong shift of resources inside Oracle to serve its (private) Cloud customers instead, almost every Oracle-led JSR aimed at Java EE 8 has been delayed.”

“Even JCache where Oracle is co-Spec Lead seems in no real shape to just be thrown into Java EE 8 with key aspects for Enterprise capability like Transactions simply missing.”

“Those missing parts are covered by proprietary vendor-specific extensions whether it’s Oracle (Coherence), Hazelcast or other vendors. Maybe that is actually how it will end up. “

“A common concern by many in the Java EE community is, that Java EE and related standards become more of a “fig leaf” to cover proprietary, mostly closed-source products or services running “in the Cloud” which you only rent and pay for.”

As a result of the seemingly changing priorities, Oracle Java EE Evangelist Reza Rahman parted ways with Oracle and founded a community driven initiative called the Java EE Guardians. “Looking at it in an unbiased way, it is nothing more or less than “Adopt-a-JSR” for Java EE. While very few attempts were made to have JUGs or its members adopt Java EE JSRs via the Adopt-a-JSR program, in reality it is limited to Java SE or standalone JSRs and pretty much all activity by Oracle and key JUGs involved focus entirely on Adopt-OpenJDK. While the Enterprise sector was in the past always seen as a thing for a few large vendors like IBM, BEA/Oracle or JBoss. “

“Having smaller players like TomiTribe or Payara contribute in Open Source ways similar to say JBoss and even IBM bet on largely Open Source driven technologies like OpenStack or WebSphere Liberty Profile means a huge shift in paradigm that at least many corporate and legal folks at Oracle don’t seem to fully understand yet.”

The Java EE Guardians

To shed some more light on the new community, we’ve got in touch with Reza Rahman for further details.

“We are a group of people passionate about Java EE that are very concerned about Oracle’s commitment to the open standards. We are committed to doing everything we can to move the Java EE community forward” – Reza Rahman

Reza continued, “Oracle and Sun have always had an unhealthy amount of influence on the direction of Java EE. Oracle’s current inactivity makes the downsides of this reality even more obvious. In the long run I think the right answer for Java EE is being driven far more actively by the community and other vendors like RedHat, IBM, Tomitribe and Payara.”

“The current status of Java EE is very worrisome. The ecosystem continues to gain strength and is as vibrant as ever with many passionate people behind it. Despite all this there is a marked slowdown in activity from Oracle resources on Oracle led JSRs. This will make it very challenging to meet the current Java EE 8 timelines unless the apparent Oracle behavior changes, the community significantly steps up contribution or other vendors make up progress gaps left from Oracle’s inactivity.”

‍