Antoine Sabot-Durand - @antoine_sd Will the Infinity War between Spring and J2EE will come to an End Game ? A short history of Enterprise Java

Antoine Sabot-Durand - @antoine_sd Will the Infinity War between Spring and Java EE will come to an End Game ? A short history of Enterprise Java

Antoine Sabot-Durand - @antoine_sd Will the Infinity War between Spring and Jakarta EE will come to an End Game ? A short history of Enterprise Java

Java Champion Java Expert Tech lead & Architect At SCIAM Ex Red Hat Former CDI Spec Lead Former MP Heath Spec Lead Follow me: @antoine_sd Antoine Sabot-Durand

Agenda Introduction The early ages Spring ascension and its consequence Vicissitudes of War Microservice Era Cloud War Conclusion

Introduction

Why this talk? Those that fail to learn from history are doomed to repeat it When Interviewing Junior (and even less junior) I realized that most enterprise Java were Spring Devs with absolutely no knowledge of Java EE existence Spring is still using part of Jakarta EE and some devs are puzzled between Speci fi cation (JPA) and implementation (Hibernate) Because I witnessed and was a very modest actor in this story

Time for the not take away Code examples Due to lack of time Total objectivity It’s my vision of the story Trolling Well let’s say an attempt of balanced trolling What is not in this talk

Timeline Major events of the war 1999 J2EE 1.0 2003 Spring 1.0 2006 Java EE 5 2014 Spring Boot 2016 MicroPro fi le 2019 Quarkus 2009 Java EE 6 (CDI) 2022 Spring Native

The forces involved - Actors (In 2022)

The forces involved - Implementations (In 2022)

The forces involved - Names and Brands (Since 2000)

Early Ages

The Java Dawn Initial work on Oak started in 1991. It became Green then Java 1996: Java First public implementation 1999: Java 2 Platform Enterprise Edition (J2EE) 1.2 is out ! This 1st version contains 10 speci fi cations (Jakarta EE 10 has 30) Prehistory

The problems with J2EE Soon, some developers started to complain Applications server are quite heavy and slow Programmation model isn’t consistent: it changes with every specs Some specs have very large dead zone leading to incompatible implementations Enterprise Java Bean concentrate the majority of critics: they require a lot of con fi guration and their code is totally coupled with the underlying framework

The Spring answer Casus Belli Rod Johnson, a computer expert decided to answer to J2EE cumbersomeness with 2 books : J2EE Design and Development in which he explains the limitation of EJB J2EE Development without EJB in which he explains how to get rid of EJB During the same period he started the development of a framework that aim to integrate the « good » J2EE part (understand not the EJB) In 2003 Spring 1.0 is released

Spring ascension and its consequence

Spring - J2EE as it should have been ? This means War ! Spring brings an elegant solution to most of the J2EE issues It provides an uni fi ed programming model By using the IoC pattern in a loose coupling approach it provides a clearer code and hides the « magic » in the spring con fi g fi le (yeah xml hell) Spring is one of the fi rst Java Framework to heavily use byte code manipulation to generate proxies at Runtime (the Bean Magic) Spring gets momentum and a nice eco system starts to fl ourish around it

Java EE side Strikes Back EJB 3, it’s back with a vengeance ! Java EE 5 (RIP J2EE) is released in 2006 it makes heavy use of annotations that papered in 2004 with Java 1.5 EJB 3.0 is complete rethinking of the spec. It provides the same components than previous version but the programming model is now completely loose coupled thanks to annotations Initiative rise from Red Hat to provide an additional framework to ease EJB integration with web-tier : it’s JBoss Seam

From Seam to CDI road to hell is paved with good intentions. JBoss Seam was a great framework thought to play a similar role than Spring in the Java EE sphere It provided a uni fi ed programming model, a nice way to link web tiers technology with EJB3 and a great ecosystem It also provided Spring integration, bringing an universal solution to bind all enterprise Java Solution Seam success gave birth to the CDI speci fi cation

CDI too high, too late? A uni fi ed programming model 6 years later Context an Dependency Injection speci fi cation was released in 2009 with Java EE 6 It’s the answer to Spring core, 6 years later It provides strong type injection, con fi g with annotations and a portable extension making framework integration as easy as possible. Yet it is only a nice engine : no eco-system comes with it

Vicissitudes of War

Spring Low blows The end justi fi es the means ? No discussion to align Spring on CDI spec The AtInject speci fi cation made Java EE 6, 6 months late and was totally useless Spring worked in some spec (like servlet) to limit CDI integration with them Spring never acknowledge CDI existence by adding a kind of support in the framework (when EJB had)

Red Hat strategic errors Why should we provide an ecosystem? Seam Framework waste : destroying value with package name Destruction of CDI ecosystem CDI for Java se standardisation was too late (2017) No communication or marketing around CDI

Microservices Era

Spring Boot Too much Magic ? In 2014, Spring boot is launched Based on Spring it allows creation of standalone Spring apps aiming micro services Spring boot provides a lot of magic and assume a lot of default approaches. Magic may be cumbersome when you don’t want the default behaviour.

The answer is MicroProfile Learning from past errors? It is an os community speci fi cation for Enterprise Java microservices It is developed within an Eclipse Foundation Working Group by individuals, organizations, and vendors

MicroProfile 5.0 MicroPro fi le 5.0 (Dec 2021)

MicroProfile Today MicroPro fi le 6.0 (Dec 2022)

Cloud War

Quarkus the cloud Native Framework Java EE community side takes the advantage Released in 2019 Cloud Native Implementing MicroPro fi le With a Rich Eco System Thanks to Graal VM, magic is done at Build Time For the fi rst time Spec Side has an advantage

Spring Native the cloud Native Framework But wait… Released in 2022 Cloud Native Based on Spring Framework With a Rich Eco System Thanks to Graal, magic is done at Build Time For the fi rst time Spring is clearly 3 years late

Conclusion

War goes on, but… Is this really a war? The competition between Jakarta EE and Spring bene fi ted the whole Java for the Enterprise eco-system: No EJB 3 and CDI without Spring No Spring Native without Quarkus In Cloud Era, standard have moved elsewhere: Containerization techs, Rest API, JSON, Cloud Events…

Questions?