Java Enterprise Edition, where have you gone?
What is the Java Enterprise Edition framework and why it is still an important part of many applications? About a year and half ago, I wrote a post about it and it’s uncertain future. Since then there has been quite a few changes and while the future is far from certain, I feel it is much brighter and certainly shouldn’t continue to be the “forgotten” Java framework.
A history of names
Probably the most confusing aspect is the many names this framework has had in the past. And because naming things is a *hard* task, here is a quick recap:
- JPE Java Platform for the Enterprise (1998)
- J2EE Java 2 Platform, Enterprise Edition (1999)
- Java EE Java Enterprise Edition (2006)
- Jakarta EE (2018) < Spoiler
Often people might be more familiar with one of the older versions and not even be aware that the framework has continued to evolve under a new name. In most cases, the older versions have (hopefully) gone the way of COBOL and retired themselves, but I often find it surprising how older technology can “linger” such that pre-2000 versions might still be used in production systems.
Why “enterprise” applications?
When your building systems, and this is especially true when building large enterprise systems, there is a natural tendency to focus on the “business logic”. Usually these are the specific rules and processes a business uses to operate. Including project time for tasks such as a new way to generate web pages, or building a library that reads and writes from a database is typically NOT included. Because of this, large organizations usually want established specifications, frameworks and tools that support these components already.
One core benefit of frameworks like the Java Enterprise Edition, it provides a neatly wrapped up set of common components needed for these large projects. Other benefits include, it is mature, well tested and often supported by large software companies.
Due to these core benefits, it’s easy to understand why enterprise application frameworks rose to such prominence and often became the cornerstone of many information technology departments.
An announcement and a new question
Java EE gets a new name!
Last September, Oracle who had acquired Java technologies from Sun in 2010, was open sourcing the framework and moving it to the Eclipse Foundation. But they unfortunately kept the name, so a new name was needed once again. After a vote by the community, the name was decided to be “Jakarta EE (JEE)”
So without pause, we will no longer refer to Java Enterprise Edition and instead use Jakarta EE!
While the Eclipse Foundation is an excellent landing pad for Jakarta EE, it does raise at least one additional question. The Eclipse Foundation already has an incubator project called the “MicroProfile” project which was started just a few years ago with the goal of “Optimizing Enterprise Java for a microservices architecture”. The MicroProfile project was based off of existing Jakarta EE technology, namely JAX-RS (web services), CDI (dependency injection), and JSON-P (serialization/deserialization).
Now that both frameworks exist under the Eclipse Foundation, what will happen to MicroProfile?
My hope to see increased collaboration between the two projects that benefit everyone in the community. Maybe MicroProfile could continue to thrive as a sub project under a larger JEE umbrella (I certainly like the idea of a common “enterprise microservice architecture”). Maybe even including support for serverless solutions like AWS Lambda.
A dire prediction, but hope remains
Back in 2016 Gartner published a report that discussed the “fading relevance” of three-tier application frameworks. Such dire predictions might be too premature. Especially given the recent change to open source. But also there is a second reason for hope.
Just recently a new version of Java was released with a key “modularization” language feature. What was previously known as project “jigsaw” and now known as “Java Platform Module System” (JPMS), this feature represents almost four years of effort to make modularization a core part of the Java ecosystem. This is important to our story because “modularization” is one of the key benefits of the any application framework. Jakarta EE has supported “modularization” through features such as “Contexts and Dependency Injection” (CDI) for quite some time. This shift in the core Java language could allow future JEE versions to compete with other alternatives, which, coupled with clear, open source ownership, gives quite a bit of hope for the future.
- Opening Up Java EE – An Update
- Java EE version history – Wikipedia
- Java Platform Module System – Wikipedia
- Market Guide for Application Platforms
- Eclipse MicroProfile – Optimizing Enterprise Java for a microservices architecture
- And the Name Is…
Have a comment, question or correction about this article? I’d love to hear from you! You can drop a message in the Disqus form below or you can direct message me on Twitter at https://twitter.com/@mjjacko