De omstreden release van Jakarta EE 9

Het woord ‘omstreden’, wat ‘veelbesproken en verschillend beoordeeld’ betekent, is een uiterst accurate beschrijving van de release van Jakarta EE 9. Deze specifieke release van het Jakarta EE platform, dat onder het bewind van Oracle de naam Java EE droeg, had nog nooit zoveel voeten in de aarde.

Auteur Edwin Derks

Aan de ene kant kampte Eclipse Foundation, de huidige eigenaar van het platform, met geforceerde wijzigingen die backwards compatibility zouden breken. Aan de andere kant was er nog nooit zoveel open-source community input gebruikt om de inhoud van een release te bepalen. In dit artikel beschrijf ik de details hiervan, en wat dit betekent voor de verdere evolutie van dit platform.

Tooling Release

Na de release van Jakarta EE 8 in september 2019 was het tijd om de inhoud van de volgende versie van dit platform, namelijk Jakarta EE 9, te gaan samenstellen. De community wilde dolgraag nieuwe features hebben voor het ontwikkelen van enterprise applicaties met Jakarta EE. Dit was logisch, want op dat gebied heeft het platform nog een behoorlijke slag in te halen met betrekking tot bleeding-edge features. Echter was er toch ook het besef dat er nog wat zaken opgeschoond moesten worden voordat het implementeren van nieuwe features in gang kon worden gezet. Na veel discussie in de community om de toekomst van Jakarta EE te bepalen, werd ‘opschoning’ uiteindelijk het doel van Jakarta EE 9. In daaropvolgende releases zou men weer gaan spreken over het implementeren van nieuwe features.

Het concept van ‘opschoning’ bracht echter een groot probleem met zich mee. Een van de heilige huisjes van Jakarta EE, namelijk backwards compatibility, kwam hierdoor in het geding. Er zijn specificaties aanwezig in het platform die hedendaags als ‘obsoleet’ werden gezien. Echter konden deze blijkbaar niet zomaar worden verwijderd. Dit zou namelijk betekenen dat bepaalde projecten niet naadloos konden migreren naar Jakarta EE 9. Voor klanten van enkele applicatieserver vendors in de community leek dit een probleem te zijn.

Daarnaast kampte de community met de door Oracle opgelegde wijziging dat alle ‘javax’ vermeldingen in de code en documentatie van de specificaties verwijderd moest worden, omdat anders merkrechten geschonden zouden worden. Echter zouden ook deze wijzigingen leiden tot het breken van backwards compatibility, ook al besefte men dat hier niet omheen te werken viel. Dit was een “moetje” geworden, waarvoor een passende oplossing gevonden moest worden. Deze situatie leidde tot vele serieuze discussies, zoals ook tijdens de Jakarta EE BoF op Oracle CodeOne 2019.

Uiteindelijk is er een gulden middenweg gevonden om deze situatie te mitigeren. De keuze was om deze referenties om te schrijven naar ‘jakarta’ en de brekende backwards compatibility te incasseren. Omdat backwards compatibility hierdoor toch al niet meer mogelijk was, heeft men gebruik gemaakt van de situatie om specificaties die naar hedendaagse standaarden als obsoleet gezien werden, optioneel te maken of te verwijderen.

Dit is in grote lijnen de inhoud voor de release van Jakarta EE 9 die uiteindelijk als ‘Tooling Release’ bestempeld werd. Dit betekende concreet dat er geen nieuwe features zouden worden geleverd in Jakarta EE 9, terwijl de release toch waarde zou moeten bieden aan bedrijven en developers, omdat het anders zinloos zou lijken om deze te adopteren.

“Backwards compatibility is geen doel voor Jakarta EE 9 en zullen we dan ook niet afdwingen. We willen met deze release een nieuwe basis leggen voor het platform”, aldus Kevin Sutter van IBM. Hij is in de lead voor de realisatie van Jakarta EE 9, ondersteund door Steve Millidge van Payara. Samen hebben zij op basis van de discussies met de community een release plan voor Jakarta EE 9 opgesteld. De belangrijke punten daaruit heb ik in de volgende paragrafen samengevat.

Waves

Om een volgorde op te stellen voor het aanpassen van de specificaties, zijn een aantal ‘waves’ opgesteld waarin sets van specificaties released werden. Deze waren voornamelijk bepaald door afhankelijkheden van specificaties onderling. Elke ‘wave’ dient compleet afgerond te zijn voordat een volgende ‘wave’ kan worden opgeleverd. Op deze manier wordt de workload van de grote lijst van aanpassingen inzichtelijk en handelbaar. Specificaties in een bepaalde ‘wave’ kunnen dan ook rekenen op een stabiele basis om de aanpassingen voor hun eigen ‘wave’ op te baseren. Zodra uiteindelijk alle ‘waves’ zijn opgeleverd zal Jakarta EE 9 worden released.

Package Rename

Zoals eerder vermeld, moet voor elke specificatie in het Jakarta EE Platform elke referentie van ‘javax’ naar ‘jakarta’ omgeschreven worden. Dat betekent dat de Java code en documentatie in de Github projecten van die specificaties, handmatig moet worden nagelopen en aangepast. Uiteindelijk resulteert dit in een ‘major’ versie ophoging van alle deliverables van die specificaties. Voor wie bekend is met bepaalde specificaties zoals EJB 3.1 en Servlet 4.0, kan een EJB 4.0 en Servlet 5.0 respectievelijk als resultaat verwachten in Jakarta EE 9.

Java SE Compatibility

Developers die uitkijken naar het bouwen van enterprise software met features uit Java SE 11+, zullen blij worden van de eisen die hiervoor zijn gedefinieerd in Jakarta EE 9. Applicatieservers moeten namelijk compatibiliteit van Jakarta EE 9 bewijzen door te runnen op Java 11. Dit is een interessante keuze omdat de specificaties zelf (voorlopig) Java SE 8 compatible blijven. Applicatieserver vendors hebben daardoor nog wel de keus om naast Java SE 11, tevens Java SE 8 compatible te blijven. Op deze manier hoeven zij hun bestaande klanten niet direct te forceren naar Java 11, dat de drempel om Jakarta EE 9 te adopteren verlaagt. Echter wil de community verder evolueren met de LTS versies van Java SE, waardoor uiteindelijk deze keuze is gemaakt.

Nieuwe Specificaties

Eerder in dit artikel is vermeld dat Jakarta EE 9 een ‘tooling release’ is, en er geen nieuwe features en specificaties worden toegevoegd. Echter was het toch nodig om enkele nieuwe specificaties aan het platform toe te voegen om het runnen op Java SE 8+ mogelijk te maken. Java SE 8 bevat namelijk nog een paar “enterprise” packages die later verwijderd zijn, omdat Oracle hier geen waarde meer in zag in voor de evolutie van Java SE. Java EE 8, en daarmee ook Jakarta EE 8, leunen qua compatibiliteit nog op het bestaan van deze “enterprise” specificaties in Java SE 8. Nu dit niet meer het geval is wanneer je Java SE 8+ wilt gebruiken, heeft men besloten deze packages als specificaties te adopteren in Jakarta EE 9 zodat Java SE 8 compatibility mogelijk blijft. Echter is wel het doel om deze uiteindelijk te verwijderen zodra de waarde hiervan verdwenen is voor de afnemers van het platform.

Optionele Specificaties

Op basis van input van de community bleek dat de vraag naar, en daarmee de ondersteuning voor, SOAP en EJB 2.x op zijn beloop is. Wederom zijn er entiteiten in de community die nog belang hebben bij aanwezigheid van dergelijke specificaties in het platform. Deze zijn echter optioneel gemarkeerd om ze in toekomstige versies te kunnen verwijderen zodra de waarde hiervoor verdwenen is.

Verwijderde Specificaties

Deze komen net als de overige specificaties die als optioneel zijn gemarkeerd, uit de XML of management hoek die hedendaags niet meer als zodanig wordt toegepast. Dit is gezien de historie en visie van het platform een ongekende wijziging, maar aan de andere kant niet meer dan logisch. De impact hiervan is relatief klein zoals bepaald op feedback van de community. Daarom is dit wellicht een mooie exercitie geweest om te ervaren hoe in de toekomst omgegaan kan worden met het uitfaseren van specificaties. Dit moet overigens niet alleen de onderhoudbaarheid, maar ook de validiteit van het platform in de toekomst ten goede komen.

Adoptie

Mocht je een enterprise applicatie gaan bouwen die op Jakarta EE 9 of later gebaseerd is, dan ondervind je van de backwards compatibility wijzigingen natuurlijk geen problemen. Echter, zit je met een project dat op Jakarta EE 8 of eerder is gebaseerd, zul je bij het adopteren van Jakarta EE 9 wijzigingen in je applicatie moeten aanbrengen. Wat zijn die wijzigingen dan precies? Zie hieronder een overzicht van de impact voor elke partij die betrokken is bij adoptie van Jakarta EE 9.

Eclipse Foundation/Community

Application Server Vendors

Java EE/Jakarta EE Developer

– javax > jakarta package wijziging

– Release nieuwe versies van specificaties, documentatie en het gehele Jakarta EE 9 platform als Maven artefacten

– Adopteer deze artifacten in Eclipse projecten (b.v. Glassfish)

– Adopteer Jakarta EE 9 Maven artefacten in de betreffende applicatie server (b.v. Payara, Wildfly, OpenLiberty)

– Adopteer de nieuwe versie van je applicatie server die op Jakarta EE 9 is gebaseerd

– Adopteer de Jakarta EE 9 Maven artefacten

– Wijzig ‘javax’ imports in de code van je Jakarta EE projecten naar ‘jakarta’

Uiteraard is de situatie voor iedereen verschillend, maar als je een actueel Jakarta EE project hebt dat goed onderhouden is, zal de impact van al deze wijzigingen minimaal zijn. Echter blijkt in de community dat dit niet voor iedereen het geval is. Er zijn gevallen waar code kwijt is, er geen budget meer is voor code aanpassingen met betrekking tot onderhoud of andere (contractuele) afspraken die adoptie van Jakarta EE 9 bemoeilijken. Er is zelfs sprake van het maken van plugins voor IDE’s die aangeven hoe en waar je Jakarta EE 9 aanpassingen moet doen in je code.

Jakarta EE 10

De marketingmachine van de Eclipse Foundation voor Jakarta EE draait op volle toeren. Naast (online) conferenties en update meetings, is er op menig conferentie een fysieke Eclipse Foundation stand aanwezig. Deze zorgt voor zichtbaarheid en op deze manier kan interactief informatie verschaft worden aan geïnteresseerden. Dit is ongekend als je het vergelijkt met de tijden van Java EE. Hierdoor wordt de community flink geprikkeld en neemt de interesse in het platform, en daarmee de vraag naar nieuwe features, toe. Dit wordt gebruikt als input voor de inhoud van Jakarta EE 10 en verder. Tijdens het schrijven van dit artikel is hier nog niet veel concreet over bekend, maar er is voldoende discussie gaande op de mailing lists en Github repositories.

Om een indruk te krijgen van wat er in de pijplijn zit, kun je daar zelf een kijkje nemen. Mocht je een feature missen voor een bepaalde specificatie, dan kun je zelf input leveren in de vorm van feedback of eventueel zelfs code. Hiermee kun je het platform laten evolueren naar jouw wensen wanneer je een Jakarta EE project overweegt of er middenin zit.

Zelf aan de slag

Mocht dit nog niet het geval zijn, probeer Jakarta EE dan eens uit en zoek een applicatieserver die bij jouw situatie past. Neem hiervoor een kijkje op de pagina met Jakarta EE gecertificeerde Jakarta EE applicatieservers. Door het programmeermodel van Jakarta EE eenmalig te leren, kun je deze kennis daarna in verschillende situaties toepassen zonder dat je weer een nieuw framework hoeft te leren. Simpelweg door een andere applicatieserver of implementatie van welke aard dan ook te gebruiken.

Conclusie

Het staat je uiteraard vrij om een mening te vormen over deze release en hoe deze aanvaard wordt door de community die gebruik maakt van het Jakarta EE platform. Op zijn minst bewijst deze release dat de Jakarta EE community divers is qua kennis, resources en flexibiliteit. Dit is deels nog voelbaar door de manier waarop het platform in de afgelopen jaren is ontwikkeld en geadopteerd onder het bewind van Oracle en de JCP, zonder dat de community hier veel inspraak in had. De eigenaarschap die de Eclipse Foundation uitdraagt nu het platform onder hun bewind valt, begint zich daadwerkelijk als open en flexibel te ontpoppen. De community heeft daadwerkelijk inspraak, waardoor het platform evolueert naar wensen van de afnemers die zich hierin bevinden. Hopelijk zet dit in positieve zin door en neemt de politieke lading die het framework draagt af en neemt de flexibiliteit toe. We gaan het meemaken, en hopelijk kan ik daar meer over vertellen in een volgend artikel.

Bio

Edwin Derks is Software Architect en CodeSmith bij Ordina JTech en heeft een passie voor alles wat met Java en cloud-driven development te maken heeft. Hij is ook contributor voor de Jakarta EE en MicroProfile communities, naast het spreken op conferenties en schrijven van artikelen.

NLJUG – Nederlandse Java User Group NLJUG – de Nederlandse Java User Group – is opgericht in 2003. De NLJUG verenigt software ontwikkelaars, architecten, ICT managers, studenten, new media developers en haar businesspartners met algemene interesse in alle aspecten van Java Technology.