Jakarta EE – De wederopstanding van Java EE.
Voordat we dieper ingaan op de titel en het onderwerp van dit artikel, wil ik jullie graag even kort meenemen in een fictieve filmtrailer. Deze trailer vat samen wat er gebeurd is met Java EE. Ook vertelt het ons waar we nu staan met Jakarta EE als opvolger van Java EE onder het bewind van de Eclipse Foundation.
Auteur: Edwin Derks
Java EE is al enkele decennia een hardwerkend en succesvol software framework. Recentelijk blijft echter zijn manier van werken achter op die van de concurrenten. Zijn klanten verliezen hun interesse, maar ook zijn werkgever: De Corporatie. Uiteindelijk wordt Java EE zelfs ontslagen en belandt hij op straat, met alleen zijn trots en ervaring op zak. Maar voordat hij volledig van het toneel verdwijnt, wordt hij gevonden door leden van ‘De Onafhankelijken’, die hem in een artificieel coma zetten en vervolgens oplappen. Ze integreren Java EE geheel in de orde van ‘De Onafhankelijken’. Dan is het moment daar. De Onafhankelijken ontwaken hem en vragen hem: “Mr. Jakarta EE, kunt u ons horen?”. En het legendarische antwoord van de als Jakarta EE herrezen Java EE is: “I’m back, with a mission!”.
Hiermee is de trailer voor Jakarta EE’s verhaal klaar. Hoe de film eruit gaat zien en wat daarin allemaal gaat gebeuren, moeten we afwachten tot de eerste release. Echter, we kunnen wel al speculeren. Ik zal jullie daarvoor in dit artikel voorzien van de feiten en visies die nu bekend zijn. Dit om een zo concreet mogelijk beeld te schetsen van waar de Eclipse Foundation met Jakarta EE naar toe wil. Pak je laptop, cola en popcorn; en geniet van de ‘film’!
Het moment van schrijven van dit artikel is december 2018. Dat vermeld ik er expliciet bij, omdat de evolutie van Jakarta EE waarschijnlijk sneller gaat dan het publiceren van dit artikel. Desalniettemin zal ik jullie van de status voorzien die op dit moment waarheid is en vervolgartikelen schrijven in volgende edities met verse updates.
De belangrijkste update is dat de migratie van de Java EE codebase vanuit Oracle nog wordt afgerond in 2019, aldus de Jakarta EE werkgroep bij de Eclipse Foundation. Daarmee zijn alle specificaties ondergebracht in een projectstructuur die gehandhaafd wordt bij Eclipse. Wil je dit proces ‘live’ volgen? Kijk dan op de status pagina die vermeld is in de referenties.
Ondanks dat officieel nog geen versie van Jakarta EE is gereleaset, worden hier al wel talks over gegeven op conferenties, door bijvoorbeeld Adam Bien. Uiteraard kon ik het niet laten om aan te schuiven bij dergelijke talks om Jakarta EE voor het eerst live te zien. Aangezien ik al behoorlijk op de hoogte ben van alles dat speelt, was ik hier wel wat sceptisch over. En terecht, want deze talks bleken uiteindelijk gewoon te gaan over Java EE en niét over Jakarta EE.
Eigenlijk is dit geniaal, want dit bewijst dat de marketingmachine van Jakarta EE wel zijn werk doet. Men komt hier mee weg, omdat de eerste versie van Jakarta EE simpelweg een Java EE 8 compliant versie is, met enkel een splinternieuwe naam en logo.
Concreet betekent dit dus dat er een Java EE 8 compliant applicatieserver moet komen die álle referentie implementaties van de voormalige Java EE 8 specificaties moet bevatten.
Niet onverwacht is de voormalige GlassFish applicatieserver, die nu Eclipse Glassfish heet, hier logischerwijs voor uitverkoren. Zodra deze stabiel bevonden is, zal Eclipse GlassFish 5.1 gereleaset worden, waarmee we daadwerkelijk aan de slag kunnen met Jakarta EE.
Er is nog een opmerkelijke update te noemen: de Technology Compatibility Kits (TCK) zijn ook open source geworden. Hiermee test je of je implementatie van een specificatie voldoet aan alle eisen. Dit is opmerkelijk, omdat deze voorheen diep waren weggestopt in de catacomben van Oracle. Hier kon je alleen gebruik van maken tegen betaling van een fiks bedrag. Op deze manier kon eigenlijk niemand (gratis) inzien wat de tests in de TCK’s nu daadwerkelijk inhielden. Dit maakte het aftesten van een referentie implementatie behoorlijk ingewikkeld. Vooral omdat het aanvechten of aanpassen van de tests een lang en bureaucratisch proces was. In mijn opinie een geniale zet van Eclipse om ook deze open source te maken, zodat iedereen deze tests kan inzien en kan verbeteren.
Na deze feiten op een rijtje te hebben gezet, ben ik gaan onderzoeken in hoeverre de roadmap van Jakarta EE al is uitgestippeld en wat al in gang is gezet voor een volgende release. Toen ik als spreker aanwezig was op de Java2Days conferentie eind november 2018, heb ik van de gelegenheid gebruik gemaakt de aanwezige Jakarta EE werkgroepleden hierover het figuurlijke hemd van het lijf te vragen. Helaas bleek dit niet erg vruchtbaar, omdat zij het simpelweg ook nog niet weten. Met de informatie die ik wél heb verkregen, kan ik in ieder geval voor jullie een concreet overzicht maken.
De kans is groot dat het versienummer formaat <<platform release>>.<<feature release>> gaat zijn, zoals dat ook bij Eclipse MicroProfile gehanteerd wordt. Het eerste versienummer van Jakarta EE als Jakarta EE 8 of Jakarta EE 8.0 zal naar verwachting gebruikt worden voor de release van GlassFish 5.1.0.
Onder het bewind van Oracle werden nieuwe specificaties behandeld door de JCP. Afgezien van het feit dat dit een tijdrovend proces was, werd hier vaak een specificatie bedacht voor wat men dacht dat een goede aanvulling zou zijn op Java EE. Er werd dan een specificatie uitgewerkt met een referentie implementatie. Daarna werd besloten of deze mee kon in een volgende Java EE release.
De Eclipse Foundation wil hier vanaf. Zij zien er meer heil in dat een tool is gemaakt door iemand vanuit een behoefte, waar dan een specificatie uit gedestilleerd kan worden. Deze wijziging moet de evolutie van Jakarta EE sneller en beter op de behoefte van de community laten passen. Overigens stappen ze ook af van referentie implementaties. Een specificatie moet één of meer productierijpe implementaties bevatten (bijvoorbeeld het originele project), maar geen officiële referentie implementatie voor een applicatieserver.
Binnen de Eclipse Foundation heeft een project zich kandidaat gesteld om dit nieuwe proces te testen: JNoSQL. Dit is een NoSQL oplossing voor Jakarta EE, want die hebben ze nog niet. Hopelijk kunnen we deze gaan gebruiken in een eerstvolgende Jakarta EE release.
De marketing van Jakarta EE predikt de toekomst van cloud-native Java. Maar wat betekent dit nou precies? Een mooie vraag van mij aan de werkgroepleden, dacht ik zelf, maar daar kreeg ik geen concreet antwoord op. Wederom omdat ze dit zelf nog niet weten. Dit concept ligt nu nog te ver open om hier concreet een richting aan te geven. Ik verwacht dat hier meer duidelijkheid in komt nadat versies van Jakarta EE gereleaset zijn, omdat de community dan wat meer ervaring hiermee heeft.
Als je op het punt staat om toch eens te gaan experimenteren met Jakarta EE, kun je daar nú al mee aan de slag. Zoals ik had vermeld, zijn Java EE 8 en Jakarta EE 8 in eerste instantie compatible en kun je dus nu al beginnen te bouwen op applicatieservers die deze specificaties implementeren.
Maar wil je dat wel? Want we weten allemaal dat applicatieservers log zijn; ‘traag’ bij opstarten en ‘gigantisch’ van formaat. Microservice frameworks, zoals Thorntail, die bijvoorbeeld MicroProfile implementeren bouwen UberJAR’s. Die starten toch veel sneller op en hebben een veel kleinere memory footprint. Toch?
Nou, volgens mij hebben we inmiddels deze mythe wel doorbroken en weten we dat deze stelling niet per definitie waar is. En het concept van een applicatieserver is ook niet per definitie ouderwets. Naar mijn mening is dit concept altijd al geniaal geweest en kan Jakarta EE daarmee nog prima uit de voeten. Jakarta EE is zelfs per ongeluk al een beetje cloud-native. Voordat je mij direct belt voor uitleg, zou ik dit willen toelichten. Het zit namelijk zo.
Een Jakarta EE applicatie die je bouwt als een WAR, is een verlengde van de applicatieservers die de specificaties implementeren. Hierdoor kun je direct gaan ontwikkelen en bouwen op je favoriete applicatieserver. Deze bevat vanwege de lange lijst aan geïmplementeerde specificaties ook ongeveer alles wat je nodig hebt voor je project.
Overigens weet je met een applicatieserver precies waar je aan toe bent qua libraries, modules en configuratie. Daarmee dus ook de versies hiervan, waaraan je kunt ontleden of deze up-to-date genoeg zijn qua security en functionaliteit die je verwacht. Probeer dit maar eens zo makkelijk duidelijk te krijgen met bijvoorbeeld Spring (Boot)… succes!
Je kunt Docker images verkrijgen voor de populaire applicatieservers zoals Payara, Wildfly en OpenLiberty. Toegegeven, deze zijn een paar honderd MB groot vanwege de applicatieserver die daarop staat. Maar is dat tegenwoordig een probleem? In de context van Docker kan dit zelfs een voordeel zijn. Denk even mee in het volgende scenario.
Je bouwt een Jakarta EE app (WAR) op een Docker image die aftakt van een Payara image. Deze WAR is, vanwege het programmeren tegen specificaties aan, maar een paar KB groot en is één enkele laag van je Docker image.
Daarna push je de gebouwde Docker image naar een repo. De eerste keer zal de volledige Docker image overgedragen worden. Een volgende push met een update van je code zal je alleen deze laag van de Docker image doen uploaden en dat is maar een paar KB. Als je dit vaak moet doen, hoef je maar steeds een paar KB te uploaden, dit in tegenstelling tot de vele MB’s die je steeds moet uploaden als je dit proces volgt met een UberJAR.
Volgens mij is de vraag die veruit het meest is gesteld in de Jakarta EE community; of MicroProfile samen gevoegd gaat worden met Jakarta EE. MicroProfile is namelijk afgetakt van Jakarta EE, maar gaat waarschijnlijk een heel andere rol als incubatie project krijgen met een eigen release cadans. Als de cadans echter gelijk gaat lopen met Jakarta EE, dan heeft dat uiteindelijk misschien weer geen zin en zullen ze wel mergen. Hoe dan ook, ik laat het jullie graag weten als hierover een besluit is genomen door de leden van de werkgroep.
Zit je intussen met het dilemma of je beter met MicroProfile aan de slag kunt, omdat je microservices wilt bouwen? Dit probleem wordt door eerdergenoemde applicatieservers opgelost. Deze implementeren namelijk niet alleen de Jakarta EE specificaties, maar óók MicroProfile. Dat betekent dat je in de WAR die je bouwt, compleet naadloos gebruik kunt maken van beide specificatie sets. Het enige wat je hoeft te doen in je project, is zowel de Jakarta EE als MicroProfile BOM als provided op te nemen in je Maven pom.xml.
Hoewel de toekomst van Jakarta EE nog wijd open ligt, hebben de leden van de werkgroep wel wensen die zij graag realiteit zien worden. Om te beginnen willen ze echt een open community creëren, waardoor input daadwerkelijk uit de community komt en niet enkel vanuit een vendor. Ze roepen dan ook nadrukkelijk op om jezelf aan te melden bij de Jakarta EE mailing list of zelfs als member van de Eclipse Foundation. Mocht je interesse hebben om het platform waar je mee gaat werken ook mee te bouwen, schroom dan niet en meld je aan.
Ze hopen zelfs dat verschillende specificaties en implementaties niet alleen van binnen, maar ook buiten de Eclipse Foundation worden gerealiseerd om op die manier verschillende platformen te kunnen bouwen, allen gebaseerd op Jakarta EE. Hierdoor heeft zelfs Microsoft zich als contributor aangemeld. Dan kun je ervan uitgaan dat we straks Jakarta EE applicaties kunnen bouwen die perfect te hosten zijn op Azure. Op deze manier verhelp je ook het probleem dat je vendor lockin zou kunnen krijgen.
Verder dromen ze van een release per kwartaal met niet alleen updates, maar ook nieuwe specificaties die een vraag voor het bouwen van cloud-native software oplossen. Denk hierbij bijvoorbeeld aan CQRS, big data en reactive functionaliteit. Als dat ook onafhankelijk kan van een specifieke Java versie, zonder backwards compatibility te breken, zou dat helemaal mooi zijn.
Jakarta EE lijkt klaar voor de toekomst. Maar hoe die eruit gaat zien, daar kunnen we nu nog weinig over zeggen. Daarvoor zullen we de ervaring van één of meerdere releases nodig hebben, naast een meer concrete visie van de werkgroepleden. Men kan in ieder geval met deze herrezen manier van werken met applicatieservers al wel de voordelen van Jakarta EE aanwijzen, maar daar zal de community wel aan moeten wennen. Zoals ik het zie, kun je prima zowel monolieten als microservices bouwen met Jakarta EE, zeker in combinatie met MicroProfile.
Kunnen we hiermee concluderen dat het gebruik van UberJAR’s voor het concept van ‘rightsizing’ je applicatie niet helemaal de potentie waarmaakt? Is Jakarta EE daarmee de start van een nieuw tijdperk voor niet alleen het bouwen, maar ook het deployen van cloud-native Java software, inclusief microservices? We zullen het meemaken, maar het is op zijn minst weer interessante gespreksstof.
