This year, enterprise Java is undergoing the biggest change in the 20-year history of the platform. Although a big part of this is the brand change from Java EE to Jakarta EE, the most important is a new openness and the technical direction. With the transition to the auspicious of the Eclipse Foundation and a new focus on cloud-native and microservices, this year demarcates a new Epoch in the story of enterprise Java.
[REVISED: changes in the timeline were made on May 12th to match feedback and corrections from the community ]
A Brief History of Enterprise Java
I like to think of the history of Enterprise Java as taking place in four Epochs, the Fourth Epoch being the latest. Each Epoch has a different platform focus with a different custodian and it is the combination of focus and custodian that defines them.
The Wild-West Epoch: The First Epoch of Enterprise Java
Developing Java enterprise applications, as opposed to desktop, mobile or embedded applications, started 22 years ago with the first release of Java 1.0 in 1996. From 1996 to 1999, a period I call the First Epoch of Enterprise Java, the nascent Java community was building enterprise systems on a hodgepodge of custom and proprietary solutions. At that time, WebLogic was a company and Tanga was their JDBC multiplexer, IBM was working on project San Francisco, IONA and Borland/Inprise were competing in the CORBA-Java market, and Apache was fiercely competing with Netscape and Microsoft in the web server market. So many choices for enterprise development, but little or no guidance from Java’s creator, Sun Microsystems. It was a Wild West of solutions; there was no vision of what enterprise Java should look like.
J2EE: The Second Epoch of Enterprise Java
The Second Epoch (1999 – 2006) arose with the release of the first version of Java 2, Enterprise Edition (J2EE) in 1999. This marks the start of the Epoch when Sun Microsystems took charge of enterprise Java and, with the cooperation of other licensees, defined a vision of a complete middleware solution for enterprise Java. The Second Epoch is marked by widespread adoptions of the platform and a race to keep pace with changing standards while the platform grew in complexity. Releases were fairly regular separated by about two years at first and then slowed dramatically after 2003. Due to the increasing complexity of the standard, this was also the time when strong alternatives to J2EE were introduced including Spring and Hibernate.
Java EE: The Third Epoch of Enterprise Java
The Third Epoch (2006 – 2017) is demarcated by a change in brand and focus of the platform. Initially, lead by Sun Microsystems and then Oracle (after their acquisition of Sun Microsystems in 2009), innovation in the Java platform remains slow as releases are every three or four years, but there was a focus on reducing complexity in the programming model. J2EE, rebranded in 2006 to Java EE, was becoming simpler. Other Java frameworks like Spring and Hibernate had set the bar for reduced complexity in the interest of productivity and Java EE was adopting much of what was being learned in the open source community. But progress was slow and the pace was starting to impact the viability of the Java EE platform. Two new paradigms in enterprise computing, cloud-native and microservices were emerging as dominate architectures and Java EE was not addressing this sea change quickly enough.
The Jakarta EE Epoch: The Fourth Epoch of Enterprise Java
The Fourth Epoch of Enterprise Java started this year with the official launch of the Jakarta EE brand and the donation of the Java EE platform by Oracle to the Eclipse Foundation. The start of the Fourth Epoch is really the beginning of a whole new platform under the auspicious of a new custodian, The Eclipse Foundation. The story of this Epoch has yet to be written, but in terms of the history of the platform, it will be very different from the past.
This is an exciting time for Enterprise Java but it’s also challenging. The Eclipse Foundation and the open source community has had a huge number of legal hurdles having to do with copyright, trademarks, and patents to overcome, but more importantly, the Eclipse Foundation has to establish a new standardization process that is unique to Eclipse, but also builds on lessons learned in the Java Community Process managed by Oracle.
Looking Ahead
One thing is certain: the Jakarta EE platform and the new standardization process will be much more responsive and have a great deal more agility than Java EE had under the JCP process. The platform will evolve more quickly to better match a change in focus from on-site, monolithic systems to cloud-native, microservices. Just as importantly, the platform will have the flexibility and the will behind it to evolve over time into new areas such as the reactive paradigm, artificial intelligence, and internet-of-things to name but a few.
Whatever direction Jakarta EE is headed, it seems more promising today than at any other time in the history of the platform. If you were involved in J2EE or Java EE in previous Epochs and have left the platform, it’s a great time to revisit what is happening and consider jumping aboard in these early stages of Jakarta EE. If you have been drawn to alternative platforms such as Node.js or Spring, consider a serious look at Jakarta EE as it evolves and modernizes. The possibilities with this new platform are endless.
