Auteur: Edwin Derks is Software Architect en CodeSmith bij Ordina JTech. Hij heeft naast Java ook een passie voor cloud-driven development en serverless architecture.

Wie zich bezig houdt met alle ontwikkelingen op het gebied van de totstandkoming van het Jakarta EE platform, kan het niet ontgaan zijn dat op 29 januari het dan eindelijk zover was… Glassfish, Oracle’s Java EE 8 compatible applicatieserver, is in zijn geheel gemigreerd naar de Eclipse Foundation. Daarmee zwemt Eclipse Glassfish 5.1 nu in de open source vijver van de Eclipse Foundation. Nu kun je denken: waarom is dit zo belangrijk? Daar zal ik je alles over vertellen in dit artikel.

Geschiedenisles

Voordat we meteen de details ingaan, wil ik jullie graag eerst even van een stukje context en geschiedenis voorzien. Als je namelijk de historie van Glassfish doorloopt, kom je erachter dat dit de oudste Java-gebaseerde applicatieserver is. Het is net zo oud als Java zelf!

Wil je hier meer over weten, dan wil ik je doorverwijzen naar de blog van Arjan Tijms (zie referentie 4). Hij vertelt daar in detail hoe de evolutie van Glassfish is verlopen. Ter illustratie: bij de start van dit project, moest ik nog beginnen aan de middelbare school! Voor mij waren veel van die details daarom ook niet bekend en dit gaf mij een beter beeld van hoe Glassfish uiteindelijk bij Oracle, en nu dus bij Eclipse is beland. Met die voorkennis is het hopelijk ook voor jullie beter te begrijpen waarom Glassfish zo’n belangrijke rol speelt in het Java ecosysteem.

Eclipse Glassfish 5.1 in een notendop

Terug naar het heden. Concreet betekent de release van Eclipse Glassfish 5.1 dat het Glassfish project zelf, en alle componenten waaruit deze server bestaat, gemigreerd zijn naar de projectstructuur en versiebeheer van de Eclipse Foundation. Als voorwaarde voor de release moesten deze worden getest met, en voldoen aan, de TCK’s (Technology Compatibility Kit). Tevens moet het ondergebracht worden als open source projecten bij Eclipse. Dit proces is online te volgen (zie referentie 1).

Maar wat heeft die migratie dan voor impact gehad op de applicatieserver zelf, naast het migreren en testen van de code? Een belangrijk detail is dat Glassfish momenteel nog een Java EE 8 compatible applicatieserver is. Dat wil zeggen dat deze voldoet aan de Java EE 8 specificaties. Dat wil echter níet zeggen dat er niets gedaan mocht worden aan de referentie implementaties van deze specificaties. Naast veel juridisch geneuzel is één van de redenen dat de migratie bijna anderhalf jaar geduurd heeft, dat de implementaties behoorlijk opgepoetst moesten worden om aan de kwaliteitseisen van Eclipse te voldoen. Er moest code herschreven worden en ook zijn dependencies vervangen, omdat ze niet meer compatibel waren, of misschien zelfs op de blacklist stonden. Wat de staat van deze server onder het bewind van Oracle ook was, het zou nu een opgefriste, moderne applicatieserver moeten zijn, die zich moet kunnen meten met de concurrenten, ook al ondersteunt Glassfish nog geen JDK nieuwer dan versie 8.

Relatie met Payara

Daarover gesproken, gebruik je Glassfish als applicatieserver in productie? Daarvoor is de commerciële support helaas al jaren geleden beëindigd door Oracle (zie referentie 8). Kun je vanwege redenen moeilijk of niet van Glassfish naar een andere Java EE vendor migreren, is het wellicht verstandig om toch eens te kijken naar Payara.

Dit is namelijk een applicatieserver die Glassfish gebruikt als basis, en voegt daar een aantal commerciële functies aan toe, inclusief productie support wanneer je dat wenst. De ontwikkelaars van deze server doen met succes hun uiterste best om voorop te lopen in adoptie van nieuwe ontwikkelingen op Java EE en MicroProfile gebied en ze staan achter hun product.

Relatie met MicroProfile

Wederom daarover gesproken, naast Java EE bestaat er nog een set van specificaties voor het Java EE ecosysteem: Eclipse MicroProfile. Veel met Glassfish concurrerende applicatieservers zoals Payara, Wildfly en OpenLiberty implementeren naast de Java EE specificaties óók de MicroProfile specificaties. Dat betekent dat je in die applicatieservers naadloos het volledige spectrum van specificaties tot je beschikking hebt, maar in Glassfish niet.

Niemand kan de toekomst voorspellen, maar ik denk dat adoptie van MicroProfile in Glassfish er niet van gaat komen. Daar is sowieso nog niet over gesproken in de discussies die gevoerd worden. Ook al hanteert Eclipse officieel geen referentie implementaties meer, Glassfish zal in ieder geval voorlopig een applicatieserver blijven die als doel heeft om compatibel implementaties van een Java EE versie als zodanig aan te bieden. En daar zitten (nog) geen MicroProfile specificaties tussen. Wellicht in de toekomst, als er onder de vorming van Jakarta EE specificaties van MicroProfile geadopteerd worden, komen de implementaties daarvan beschikbaar in Glassfish. We zullen meemaken hoe dit gaat lopen.

Toekomst van Glassfish

Tot die tijd kunnen we discussiëren of er zonder productiesupport en MicroProfile implementaties wel een toekomst is voor Glassfish als applicatieserver. Zeker als deze applicatieserver mee moet in de cloud-native Java-visie van Eclipse, zoals ze die voor ogen hebben met Jakarta EE.

Vergeet echter niet dat het migreren van Glassfish wel één van de belangrijkste milestones was om het Jakarta EE platform van de grond te krijgen. In één van de laatste Jakara EE Town Hall Meetups (zie referentie 6) is een presentatie gegeven over de status van Jakarta EE, met de focus op hoe Glassfish daar een plekje in heeft.

 

Hierin kunnen we zien dat Glassfish 5.1 nog een officiële Java EE 8 compatible applicatieserver is. Nu aan Eclipse en de community de taak om daadwerkelijk alles te rebranden naar Jakarta EE 8 en Glassfish 5.2 hiermee te releasen. Dat zal de situatie voor iedereen (inclusief de schrijver van dit artikel) makkelijker maken en kunnen we daadwerkelijk uitkijken naar nieuwe specificaties voor het Jakarta EE platform, zoals JNoSQL.

Conclusie

Ik realiseerde me dat bij de geboorte van Jakarta EE 8, het Java EE label tegelijkertijd daadwerkelijk begraven werd. In eerste instantie vond ik het jammer dat het Java EE label, met zijn rijke historie en waar ik zelf zoveel mee gewerkt heb, te gronde gaat.

Er is echter een grote maar! Zoals de geschiedenis van Glassfish dicteert, kun je na 25 jaar meerdere malen gerebrand en vertimmerd te zijn, sterk uit de bus komen als een volwassen product waar mensen van houden en graag in hun dagelijkse leven mee werken. Hopelijk is de evolutie naar Jakarta EE daarmee een mooie stap voor het platform, met Glassfish als solide basis daarvoor.