streamalism.org

1. Inleiding

Ooit gehoord van Java EE? Hoe zit het met Java 2EE, J2EE of nu Jakarta EE? Werkelijk, dit zijn allemaal verschillende namen voor hetzelfde: een set bedrijfsspecificaties die Java SE uitbreiden.

In dit korte artikel beschrijven we de evolutie van Java EE.

2. Geschiedenis

In de eerste versie van Java waren Java-enterprise-extensies gewoon een onderdeel van de kern-JDK.

Toen, als onderdeel van Java 2 in 1999, werden deze extensies uit de standaard binaries gehaald, en J2EE, of Java 2 Platform Enterprise Edition, was geboren. Het zou die naam behouden tot 2006.

Voor Java 5 in 2006 werd J2EE hernoemd naar Java EE of Java Platform Enterprise Edition. Die naam zou tot september 2017 blijven bestaan, toen er iets belangrijks gebeurde.

Zie, in september 2017 besloot Oracle om de rechten voor Java EE weg te geven aan de Eclipse Foundation (de taal is nog steeds eigendom van Oracle).

3. In overgang

Eigenlijk is de Eclipse Foundation legaal had om Java EE te hernoemen. Dat komt omdat Oracle de rechten heeft over het merk "Java".

Dus om de nieuwe naam te kiezen, heeft de community gestemd en gekozen: Jakarta EE. Op een bepaalde manier is het nog steeds JEE.

* Nieuwe naam aangekondigd

Dit is echter nog steeds een evoluerend verhaal en het stof is nog niet helemaal neergedaald.

Hoewel Oracle bijvoorbeeld de broncode open source heeft gemaakt, hebben ze niet alle documentatie open source gemaakt. Er is nog veel discussie over deze kwestie vanwege juridische kwesties die het lastig maken om open-source documentatie met betrekking tot bijvoorbeeld JMS en EJB te maken.

Het is nog niet duidelijk of de nieuwe documentatie van de Eclipse Foundation naar de originelen kan verwijzen.

Vreemd genoeg kan de Eclipse Foundation geen nieuwe Java-pakketten maken met de Javax namespace, maar het kan nieuwe klassen en subklassen maken onder de bestaande.

De overgang betekent ook een nieuw proces voor het toevoegen van specificaties aan Jakarta EE. Om het beter te begrijpen, laten we eens kijken hoe dat proces was onder Oracle en hoe het verandert onder de Eclipse Foundation.

4. De toekomst

Historisch gezien hadden we drie dingen nodig om een ​​functie in "EE" te veranderen: een specificatie, een referentie-implementatie en tests. Deze drie dingen zouden door iedereen in de gemeenschap kunnen worden geleverd, en een uitvoerend comité zou beslissen wanneer deze klaar waren om aan de taal toe te voegen.

Laten we, om het proces uit het verleden beter te begrijpen, wat nader bekijken JSR's, Glassfish en de TCK zijn en hoe ze nieuwe EE-functies belichaamden.

We zullen ook een glimp opvangen van wat we in de toekomst kunnen verwachten.

4.1. De JCP en Now, de EFSP

In het verleden werd het proces waarmee een nieuwe EE-functie werd geboren, het Java Community Process (JCP) genoemd.

Java SE gebruikt nog steeds de JCP. Maar sinds EE van eigenaar is veranderd, van Oracle naar de Eclipse Foundation, hebben we daarvoor een nieuw en apart proces. Het is het Eclipse Foundation Specification Process (EFSP) en het is een uitbreiding van het Eclipse Development Process.

Er zijn echter enkele belangrijke verschillen, meestal rond "Transparantie, Openheid, Gedeelde Lasten en Leveranciersneutraliteit". De EFSP-organisatoren stellen zich bijvoorbeeld samenwerkende werkgroepen voor die vendor-neutraal zijn, een certificeringsproces dat zelfbediening is en een organisatie die opereert en regeert als een meritocratie.

4.2. JSRs

In het JCP was de eerste stap bij het toevoegen van een functie aan EE het maken van een JSR- of Java-specificatieverzoek. De JSR leek een beetje op de koppel voor een EE-functie. Het JCP Executive Committee beoordeelde en keurde een voltooide JSR goed, en vervolgens zouden JSR-bijdragers het coderen en beschikbaar stellen aan de gemeenschap.

Een goed voorbeeld hiervan was JSR-339 - of JAX-RS - die oorspronkelijk in 2011 werd voorgesteld, in 2012 door JCP werd goedgekeurd en uiteindelijk in 2013 werd uitgebracht.

En hoewel de gemeenschap altijd kon meewegen terwijl een specificatie werd besproken, toonde de tijd aan dat een implementatie-eerst-benadering - zoals in het geval van JSR 310, java.time, en Joda Time - hadden de neiging om meer algemeen aanvaarde functies en API's te creëren.

Dus de EFSP weerspiegelt deze code-first-visie in zijn gestelde doel: "EFSP zal eerst gebaseerd zijn op hands-on experimenteren en coderen, als een manier om te bewijzen dat iets het waard is om in een specificatie te documenteren."

4.3. Glasvis

Vervolgens had een JSR, als onderdeel van het JCP, een referentie-implementatie nodig. Dit lijkt een beetje op de klasse dat implementeert de koppel. Een referentie-implementatie helpt ontwikkelaars van compatibele bibliotheken of andere organisaties die hun eigen implementatie van de specificatie willen creëren.

Voor Java EE-functies gebruikte de JCP Glassfish voor zijn referentie-implementaties.

En hoewel deze centralisatie op Glassfish het ontdekkingsproces voor implementeerders vereenvoudigde, vereiste die centralisatie ook meer beheer en had ze de neiging om de ene leverancier te bevoordelen boven de andere.

Daarom vereist de EFSP geen referentie-implementatie, maar in plaats daarvan alleen een verenigbaar implementatie. Simpel gezegd, deze subtiele verandering zorgt ervoor dat implementaties binnen een centrale architectuur, zoals Glassfish, zullen niet per ongeluk de voorkeur krijgen van de stichting.

4.4. TCK

Ten slotte vereiste de JCP dat EE-functies werden getest via de Technology Compatibility Kit of TCK.

De TCK was een reeks tests om een ​​specifieke EE JSR te valideren. Simpel gezegd, om te voldoen aan Java EE, moet een applicatieserver al zijn JSR's implementeren en alle tests op de aangewezen TCK doorstaan.

Hier verandert niet veel. Oracle heeft zowel de TCK als de EE JSR's open source gemaakt. Uiteraard zullen alle toekomstige documenten en de TCK open-source zijn.

5. Conclusie

Java EE is in die jaren zeker enorm geëvolueerd. Het is leuk om te zien dat het blijft veranderen en verbeteren.

Er staan ​​nog veel uitdagingen te wachten, dus laten we hopen op een soepele overgang.