Java EE vs J2EE vs Jakarta EE

1. Introduktion

Nogensinde hørt om Java EE? Hvad med Java 2EE, J2EE eller nu Jakarta EE? Rent faktisk, disse er alle forskellige navne til den samme ting: et sæt virksomhedsspecifikationer, der udvider Java SE.

I denne korte artikel beskriver vi udviklingen af ​​Java EE.

2. Historie

I den første version af Java var Java-virksomhedsudvidelser simpelthen en del af kernen i JDK.

Derefter blev disse udvidelser, som en del af Java 2 i 1999, brudt ud af standardbinarierne, og J2EE, eller Java 2 Platform Enterprise Edition, blev født. Det ville beholde dette navn indtil 2006.

For Java 5 i 2006 blev J2EE omdøbt til Java EE eller Java Platform Enterprise Edition. Det navn ville holde sig helt til september 2017, når der skete noget større.

Se, i september 2017 besluttede Oracle at give væk rettighederne til Java EE til Eclipse Foundation (sproget ejes stadig af Oracle).

3. I overgang

Faktisk Eclipse Foundation lovligt havde for at omdøbe Java EE. Det er fordi Oracle har rettighederne over "Java" -mærket.

Så for at vælge det nye navn stemte og valgte samfundet: Jakarta EE. På en bestemt måde er det stadig JEE.

* Nyt navn annonceret

Dette er dog stadig en historie i udvikling, og støvet har ikke lagt sig helt.

For eksempel, mens Oracle open source-kildekoden, open-source de ikke al dokumentation. Der er stadig en masse diskussioner om denne sag på grund af juridiske problemer, der gør det vanskeligt at open source-dokumentation relateret til for eksempel JMS og EJB.

Det er endnu ikke klart, om ny Eclipse Foundation-dokumentation kan henvise til originalerne.

Også underligt kan Eclipse Foundation ikke oprette nye Java-pakker ved hjælp af javax navneområde, men det kan oprette nye klasser og underklasser under de eksisterende.

Overgangen betyder også en ny proces til tilføjelse af specifikationer til Jakarta EE. For at forstå det bedre, lad os se på, hvordan processen var under Oracle, og hvordan den ændres under Eclipse Foundation.

4. Fremtiden

Historisk set havde vi brug for tre ting for at en funktion kunne gøre det til "EE": en specifikation, en referenceimplementering og test. Disse tre ting kunne leveres af alle i samfundet, og en eksekutivkomité ville beslutte, hvornår disse var klar til at føje til sproget.

For bedre at forstå den tidligere proces, lad os se nærmere på hvad JSR'er, Glassfish og TCK er, og hvordan de indeholdt nye EE-funktioner.

Vi får også et glimt af, hvad vi kan forvente i fremtiden.

4.1. JCP og nu, EFSP

Tidligere blev den proces, hvorved en ny EE-funktion blev født, kaldet Java Community Process (JCP).

Java SE bruger stadig JCP i dag. Men da EE har skiftet ejerskab, fra Oracle til Eclipse Foundation, har vi en ny og separat proces til det. Det er Eclipse Foundation Specification Process (EFSP), og det er en udvidelse af Eclipse Development Process.

Der er dog nogle vigtige forskelle, hovedsagelig omkring ”Transparens, åbenhed, delt byrde og leverandørneutralitet”. EFSP-arrangørerne forestiller sig f.eks. Samarbejdsgrupper, der er leverandørneutrale, en certificeringsproces, der er selvbetjening, og en organisation, der driver og styrer som et meritokrati.

4.2. JSR'er

I JCP var det første skridt til at tilføje en funktion til EE at oprette en JSR- eller Java-specifikationsanmodning. JSR var lidt ligesom interface til en EE-funktion. JCP's eksekutivkomité gennemgik og godkendte en færdig JSR, og derefter ville JSR-bidragydere kode den op og gøre den tilgængelig for samfundet.

Et godt eksempel på dette var JSR-339 - eller JAX-RS - som oprindeligt blev foreslået i 2011, godkendt af JCP i 2012 og endelig frigivet i 2013.

Og mens samfundet altid kunne veje ind, mens en specifikation var under diskussion, viste tiden, at en implementerings-første tilgang - som i tilfældet med JSR 310, java.time, og Joda Time - havde tendens til at skabe mere bredt accepterede funktioner og API'er.

Så EFSP afspejler denne kode-første opfattelse i sit erklærede mål: "EFSP vil være baseret på praktisk eksperimentering og kodning først, som en måde at bevise, at noget er værd at dokumentere i en specifikation."

4.3. Glasfisk

Derefter, som en del af JCP, havde en JSR behov for en referenceimplementering. Dette er lidt ligesom klasse der implementerer interface. En referenceimplementering hjælper udviklere af kompatible biblioteker eller andre organisationer, der ønsker at oprette deres egen implementering af specifikationen.

Til Java EE-funktioner brugte JCP Glassfish til sine referenceimplementeringer.

Og mens denne centralisering på Glassfish forenklede opdagelsesprocessen for implementatorer, krævede centraliseringen også mere styring og havde en tendens til at favorisere en leverandør frem for en anden.

Derfor kræver EFSP ikke en referenceimplementering, men i stedet kun en kompatibel implementering. Kort sagt, denne subtile ændring gør det implementeringer inde i en central arkitektur, som Glassfish, foretrækkes ikke utilsigtet af fundamentet.

4.4. TCK

Endelig krævede JCP, at EE-funktioner blev testet gennem Technology Compatibility Kit eller TCK.

TCK var en række tests til validering af en specifik EE JSR. Kort fortalt, For at overholde Java EE skal en applikationsserver implementere alle sine JSR'er og bestå alle testene på den udpegede TCK.

Der ændres ikke meget her. Oracle har open source TCK såvel som EE JSR'erne. Naturligvis vil alle fremtidige dokumenter og TCK være open source.

5. Konklusion

Java EE har bestemt udviklet sig meget i disse år. Det er rart at se, at det fortsætter med at ændre sig og forbedre sig.

Der er mange udfordringer, så lad os håbe på en jævn overgang.


$config[zx-auto] not found$config[zx-overlay] not found