streamalism.org

1. Uvod

Jeste li ikad čuli za Java EE? Može Java 2EE, J2EE ili sada Jakarta EE? Zapravo, sve su to različiti nazivi za istu stvar: skup poslovnih specifikacija koji proširuju Java SE.

U ovom ćemo kratkom članku opisati razvoj Java EE.

2. Povijest

U prvoj verziji Jave, Java poduzeća proširenja su jednostavno dio jezgre JDK.

Tada su, kao dio Jave 2 1999. godine, ova proširenja izbijena iz standardnih binarnih datoteka, i J2EE, ili Java 2 Platform Enterprise Edition, je rođen. To ime zadržalo bi do 2006. godine.

Za Javu 5 2006. godine J2EE je preimenovan u Java EE ili Java Platform Enterprise Edition. To bi se ime zadržalo sve do rujna 2017., kad se dogodilo nešto glavno.

Pogledajte, u rujnu 2017. Oracle je odlučio ustupiti prava za Java EE Zakladi Eclipse (jezik je i dalje u vlasništvu Oraclea).

3. U tranziciji

Zapravo, Eclipse Foundation legalno imao za preimenovanje Java EE. To je zato što Oracle ima prava na marku "Java".

Dakle, za odabir novog imena, zajednica je glasala i izabrala: Jakarta EE. Na određeni način, to je i dalje JEE.

* Objavljeno novo ime

Ovo je ipak priča koja se razvija i prašina se nije potpuno slegla.

Primjerice, dok je Oracle izvornog koda otvorenog izvora, nije otvorio svu dokumentaciju. O tome se još uvijek puno raspravlja zbog pravnih pitanja zbog kojih je nezgodno pristupiti dokumentaciji otvorenog koda koja se odnosi, na primjer, na JMS i EJB.

Još nije jasno hoće li se nova dokumentacija Eclipse Foundation moći pozivati ​​na originale.

Također, zanimljivo je da Eclipse Foundation ne može stvoriti nove Java pakete pomoću javax prostor imena, ali može stvoriti nove klase i podrazrede pod postojećim.

Prijelaz također znači novi postupak za dodavanje specifikacija u Jakarta EE. Da bih to bolje razumio, pogledajmo kakav je taj proces bio pod Oracleom i kako se mijenja pod Zakladom Eclipse.

4. Budućnost

Povijesno gledano, da bi značajka mogla ući u "EE", trebale su nam tri stvari: specifikacija, referentna provedba i testovi. Te tri stvari mogao bi pružiti bilo tko u zajednici, a izvršni odbor bi odlučivao kada bi to bilo spremno dodati jeziku.

Da bismo bolje razumjeli prošli proces, pogledajmo pobliže što JSR-ovi, Glassfish i TCK jesu i kako su utjelovili nove EE značajke.

Također ćemo uvidjeti što možemo očekivati ​​u budućnosti.

4.1. JCP i sada, EFSP

U prošlosti se proces kojim se rodila nova značajka EE zvao Java Community Process (JCP).

Java SE i danas koristi JCP. No, budući da je EE promijenio svoje vlasništvo, iz Oraclea u Eclipse Foundation, za to imamo novi i zasebni postupak. To je postupak specifikacije Eclipse Foundation (EFSP) i produžetak je postupka razvoja Eclipsea.

Postoje neke važne razlike, uglavnom oko "Transparentnosti, otvorenosti, zajedničkog tereta i neutralnosti prodavača". Na primjer, organizatori EFSP-a predviđaju suradničke radne skupine koje su neutralne prema dobavljačima, postupak certificiranja koji se služi samoposluživanjem i organizaciju koja djeluje i vlada kao meritokracija.

4.2. JSR

U JCP-u, prvi korak za dodavanje značajke u EE bio je stvaranje zahtjeva za specifikacijom JSR-a ili Java-e. JSR je bio pomalo sličan sučelje za značajku EE. Izvršni odbor JCP pregledao je i odobrio ispunjeni JSR, a zatim bi ga suradnici JSR kodirali i učinili dostupnim zajednici.

Dobar primjer za to bio je JSR-339 - ili JAX-RS - koji je izvorno predložen 2011. godine, odobren od strane JCP 2012. i konačno objavljen 2013. godine.

I dok je zajednica uvijek mogla odvagnuti dok se o specifikaciji raspravljalo, vrijeme je pokazalo da je pristup koji je prvi od implementacije - kao u slučaju JSR 310, java.time, i Joda Time - nastojali su stvoriti šire prihvaćene značajke i API-je.

Dakle, EFSP odražava ovo prvobitno stajalište u svom navedenom cilju: „EFSP će se prvo temeljiti na praktičnom eksperimentiranju i kodiranju, kao način da se dokaže da je nešto vrijedno dokumentiranja u specifikaciji.“

4.3. Staklena ribica

Tada je, kao dio JCP, JSR trebao referentnu provedbu. Ovo je pomalo kao razred koja provodi sučelje. Referentna implementacija pomaže programerima kompatibilnih knjižnica ili drugim organizacijama koje žele stvoriti vlastitu implementaciju specifikacije.

Za Java EE značajke, JCP je za referentne implementacije koristio Glassfish.

I dok je ova centralizacija na Glassfishu pojednostavila postupak otkrivanja za implementatore, ta centralizacija također je zahtijevala više upravljanja i imala je tendenciju davati prednost jednom dobavljaču nad drugim.

Stoga EFSP ne zahtijeva referentnu implementaciju, već samo a kompatibilan provedba. Jednostavno rečeno, ova suptilna promjena čini tako da Zaklada neće nehotice preferirati implementacije unutar središnje arhitekture, poput Glassfish-a.

4.4. TCK

Konačno, JCP je zahtijevao da se značajke EE testiraju putem Technology Compatibility Kit ili TCK.

TCK je bio niz testova za potvrdu određenog EE JSR. Jednostavno rečeno, kako bi se uskladio s Java EE, aplikacijski poslužitelj mora implementirati sve svoje JSR-ove i proći sve testove na naznačenom TCK-u.

Ovdje nema puno promjena. Oracle je otvorio TCK, kao i EE JSR-ove. Naravno, svi budući dokumenti i TCK bit će otvoreni.

5. Zaključak

Java EE je zasigurno puno evoluirao tijekom tih godina. Lijepo je vidjeti da se nastavlja mijenjati i poboljšavati.

Puno je izazova pa se nadamo glatkoj tranziciji.