Java EE vs J2EE vs Jakarta EE
1. Úvod
Počuli ste už o Java EE? Čo tak Java 2EE, J2EE alebo teraz Jakarta EE? Vlastne, to sú všetko rôzne názvy toho istého: sada podnikových špecifikácií, ktoré rozširujú Java SE.
V tomto krátkom článku si popíšeme vývoj Java EE.
2. História
V prvej verzii Javy boli podnikové rozšírenia Java jednoducho súčasťou základnej JDK.
Potom, ako súčasť Java 2 v roku 1999, boli tieto rozšírenia vylomené zo štandardných binárnych súborov a J2EEalebo Java 2 Platform Enterprise Edition. Toto meno by si udržalo až do roku 2006.
Pre verziu Java 5 v roku 2006 sa J2EE premenovalo na Java EE alebo Java Platform Enterprise Edition. Tento názov by sa držal až do septembra 2017, keď sa stalo niečo zásadné.
V septembri 2017 sa spoločnosť Oracle rozhodla udeliť práva pre Java EE nadácii Eclipse Foundation (jazyk stále vlastní spoločnosť Oracle)..
3. V prechode
Vlastne nadácia Eclipse legálne mal premenovať Java EE. Je to preto, že spoločnosť Oracle má práva na značku „Java“.
Komunita teda zvolila nový názov a hlasovala a vybrala: Jakarta EE. Určitým spôsobom je to stále JEE.
* Bolo oznámené nové meno
Toto je stále vyvíjajúci sa príbeh a prach sa úplne nezastavil.
Napríklad keď spoločnosť Oracle otvorila zdrojový kód, nespustila open-source všetku dokumentáciu. O tejto záležitosti stále veľa diskutuje kvôli právnym problémom, ktoré sťažujú prístup k dokumentácii otvoreného zdroja týkajúcej sa napríklad JMS a EJB.
Zatiaľ nie je jasné, či sa nová dokumentácia Eclipse Foundation bude môcť odvolávať na originály.
Je tiež kuriózne, že Eclipse Foundation nemôže vytvárať žiadne nové Java balíčky pomocou javax menný priestor, ale môže vytvoriť nové triedy a podtriedy pod existujúcimi.
Prechod znamená aj nový proces pridávania špecifikácií do Jakarty EE. Aby sme tomu lepšie porozumeli, Poďme sa pozrieť na to, aký bol tento proces v spoločnosti Oracle a ako sa mení v rámci Eclipse Foundation.
4. Budúcnosť
Z historického hľadiska sme potrebovali tri veci, aby sa funkcia dostala do „EE“: špecifikácia, referenčná implementácia a testy. Tieto tri veci mohol poskytnúť ktokoľvek v komunite a výkonný výbor rozhodne, keď budú pripravení pridať sa do jazyka.
Aby sme lepšie porozumeli minulému procesu, pozrime sa bližšie, čo Spoločnosti JSR, Glassfish a TCK sú a ako stelesňujú nové funkcie EE.
Taktiež sa dozvieme, čo môžeme očakávať v budúcnosti.
4.1. JCP a teraz, EFSP
V minulosti sa proces, pri ktorom sa zrodila nová funkcia EE, nazýval Java Community Process (JCP).
Java SE dodnes používa JCP. Ale keďže spoločnosť EE zmenila svoje vlastníctvo, z Oracle na Eclipse Foundation, máme k dispozícii nový a samostatný proces. Je to proces špecifikácie Eclipse Foundation (EFSP) a je rozšírením vývojového procesu Eclipse.
Existujú však niektoré dôležité rozdiely, väčšinou okolo „Transparentnosti, otvorenosti, zdieľaného bremena a neutrality dodávateľov“. Napríklad organizátori EFSP predpokladajú spolupracujúce pracovné skupiny, ktoré sú neutrálne voči predajcom, certifikačný proces, ktorý je samoobslužný, a organizáciu, ktorá funguje a vládne ako meritokracia.
4.2. JSR
V JCP bolo prvým krokom k pridaniu funkcie do EE vytvorenie požiadavky na špecifikáciu JSR alebo Java. JSR bol trochu ako rozhranie pre funkciu EE. Výkonný výbor JCP skontroloval a schválil dokončené JSR a potom prispievatelia JSR ho kódovali a sprístupnili komunite.
Dobrým príkladom toho bol JSR-339 - alebo JAX-RS - ktorý bol pôvodne navrhnutý v roku 2011, schválený JCP v roku 2012 a nakoniec vydaný v roku 2013.
A zatiaľ čo komunita mohla vždy váhať, keď sa diskutovalo o špecifikácii, čas ukázal, že prístup založený na implementácii - ako v prípade JSR 310, java.time, a Joda Time - majú tendenciu vytvárať všeobecne akceptovanejšie funkcie a API.
EFSP teda odráža tento pohľad na prvý kód vo svojom stanovenom cieli: „EFSP bude založený najskôr na praktickom experimentovaní a kódovaní, ako na spôsobe, ako dokázať, že niečo je hodné dokumentácie v špecifikácii.“
4.3. Glassfish
Potom ako súčasť JCP potreboval JSR referenčnú implementáciu. Je to trochu ako trieda ktorý vykonáva rozhranie. Referenčná implementácia pomáha vývojárom kompatibilných knižníc alebo iným organizáciám, ktoré chcú vytvoriť vlastnú implementáciu špecifikácie.
Pre funkcie Java EE použil JCP ako referenčné implementácie Glassfish.
A hoci táto centralizácia na Glassfish zjednodušila proces zisťovania pre implementátorov, vyžadovala tiež viac riadenia a mala tendenciu uprednostňovať jedného dodávateľa pred druhým.
Preto EFSP nevyžaduje referenčnú implementáciu, ale iba a kompatibilný implementácia. Jednoducho povedané, táto jemná zmena to robí preto implementácie vo vnútri centrálnej architektúry, napríklad Glassfish, nadácia neúmyselne neuprednostní.
4.4. TCK
Nakoniec JCP požadovalo, aby sa funkcie EE testovali prostredníctvom súpravy Technology Compatibility Kit alebo TCK.
TCK bola sada testov na validáciu konkrétneho EE JSR. Jednoducho povedané, aby bol aplikačný server v súlade s Java EE, musí implementovať všetky svoje JSR a absolvovať všetky testy na určenom TCK.
Tu sa veľa nezmení. Spoločnosť Oracle otvorila zdroje TCK, ako aj EE JSR. Samozrejme, všetky budúce dokumenty a TCK budú open-source.
5. Záver
Java EE sa za tie roky určite veľa vyvinula. Je pekné vidieť, že sa to neustále mení a zlepšuje.
Je pred nami veľa výziev, takže dúfajme v hladký prechod.
