streamalism.org

1. Bemutatkozás

Hallottál már a Java EE-ről? Mit szólnál a Java 2EE, J2EE vagy most Jakarta EE-hez? Tulajdonképpen, ezek mind ugyanazon dolog különböző elnevezései: a Java SE kiterjesztését lehetővé tevő vállalati specifikációk összessége.

Ebben a rövid cikkben leírjuk a Java EE fejlődését.

2. Történelem

A Java első verziójában a Java vállalati kiterjesztések egyszerűen a JDK mag részét képezték.

Ezután a Java 2 részeként 1999-ben ezeket a kiterjesztéseket kibontották a szabványos bináris fájlokból, és J2EE, vagy a Java 2 Platform Enterprise Edition született. 2006-ig megtartaná ezt a nevet.

A Java 5 esetében 2006-ban a J2EE átnevezésre került: Java EE vagy Java Platform Enterprise Edition. Ez a név 2017 szeptemberéig maradna, amikor valami nagyobb dolog történt.

Lásd: 2017 szeptemberében az Oracle úgy döntött, hogy átadja a Java EE jogait az Eclipse Alapítványnak (a nyelv továbbra is az Oracle tulajdonában van).

3. Átmenetben

Valójában az Eclipse Alapítvány legálisan volt hogy átnevezzük a Java EE-t. Ennek oka, hogy az Oracle-nek jogai vannak a „Java” márkanévvel szemben.

Tehát az új név kiválasztásához a közösség megszavazta és kiválasztotta: Jakarta EE. Bizonyos módon még mindig az JEE.

* Új név bejelentve

Ez azonban még mindig fejlődő történet, és a por nem ült le teljesen.

Például, míg az Oracle nyílt forrásból szerezte be a forráskódot, nem nyitották meg az összes dokumentációt. Még mindig sok vita folyik erről az ügyről olyan jogi kérdések miatt, amelyek bonyolulttá teszik a nyílt forráskódú dokumentációkat, például a JMS-hez és az EJB-hez kapcsolódóan.

Egyelőre nem világos, hogy az új Eclipse Foundation dokumentáció képes lesz-e hivatkozni az eredetire.

Érdekes módon az Eclipse Foundation nem tud új Java csomagokat létrehozni a javax névtér, de új osztályokat és alosztályokat hozhat létre a meglévők alatt.

Az átállás új eljárást is jelent a specifikációk hozzáadásához a Jakarta EE-hez. Hogy jobban megértsem, nézzük meg, milyen volt ez a folyamat az Oracle alatt, és hogyan változik az Eclipse Alapítvány alatt.

4. A jövő

Történelmileg három dologra volt szükségünk ahhoz, hogy egy funkció „EE” -vé váljon: specifikáció, referencia megvalósítás és tesztek. Ezt a három dolgot bárki megadhatja a közösségben, és a Végrehajtó Bizottság dönt arról, hogy mikor készek hozzáadni a nyelvet.

A múlt folyamat jobb megértése érdekében nézzük meg közelebbről, hogy mi A JSR-k, az Glassfish és a TCK az új EE-funkciók megtestesítői.

Bepillantást nyerhetünk arra is, hogy mire számíthatunk a jövőben.

4.1. A JCP és most, az EFSP

Korábban azt a folyamatot, amellyel egy új EE szolgáltatás született, Java közösségi folyamatnak (JCP) neveztek.

A Java SE ma is használja a JCP-t. De mivel az EE megváltoztatta tulajdonjogát, az Oracle-től az Eclipse Alapítványig, erre új és külön folyamatunk van. Ez az Eclipse Alapítvány specifikációs folyamata (EFSP) és az Eclipse fejlesztési folyamat kiterjesztése.

Van néhány fontos különbség, főleg az „Átláthatóság, nyitottság, megosztott teher és a szállító semlegessége” körül. Az EFSP szervezői például olyan szállító-semleges együttműködő munkacsoportokat, önkiszolgáló tanúsítási folyamatokat, valamint meritokráciaként működő és kormányzó szervezeteket képzelnek el.

4.2. JSR-k

A JCP-ben egy szolgáltatás EE-hez való hozzáadásának első lépése egy JSR vagy Java specifikációs kérelem létrehozása volt. A JSR kicsit hasonlított a felület EE funkcióhoz. A JCP Végrehajtó Bizottsága felülvizsgálta és jóváhagyta a befejezett JSR-t, majd a JSR közreműködői kódolják és hozzáférhetővé teszik a közösség számára.

Jó példa erre a JSR-339 - vagy JAX-RS - volt, amelyet eredetileg 2011-ben javasoltak, a JCP 2012-ben hagyott jóvá és végül 2013-ban jelent meg.

És bár a közösség mindig mérlegelhetett egy specifikáció megvitatása közben, az idő azt mutatta, hogy a megvalósítás első megközelítése - mint például a JSR 310 esetében, java.time, és a Joda Time - hajlamosak szélesebb körben elfogadott funkciók és API-k létrehozására.

Tehát az EFSP ezt a kódelső nézetet tükrözi a kitűzött célban: „Az EFSP először a gyakorlati kísérleteken és a kódoláson fog alapulni, mivel annak bizonyítása, hogy valamit érdemes specifikációban dokumentálni.”

4.3. Üveghal

Ezután a JCP részeként egy JSR-nek referencia-megvalósításra volt szüksége. Ez egy kicsit hasonlít a osztály hogy megvalósítja a felület. A referencia megvalósítás segít a kompatibilis könyvtárak vagy más szervezetek fejlesztőinek, akik saját maguk akarják létrehozni a specifikációt.

A Java EE szolgáltatásaihoz a JCP a Glassfish-t használta referencia-megvalósításaihoz.

És bár ez a Glassfish központosítás leegyszerűsítette a megvalósítók felfedezési folyamatát, ez a centralizálás szintén nagyobb irányítást igényelt, és hajlamos volt az egyik szállítót előnyben részesíteni a másikkal szemben.

Ennélfogva az EFSP nem igényel referencia-megvalósítást, ehelyett csak a összeegyeztethető végrehajtás. Egyszerűen fogalmazva, ez a finom változás ezt teszi Az alapítvány nem akarja véletlenül előnyben részesíteni a központi architektúrán belüli megvalósításokat, például az Glassfish-t.

4.4. TCK

Végül a JCP megkövetelte, hogy az EE funkciókat a Technology Compatibility Kit vagy a TCK segítségével teszteljék.

A TCK egy tesztcsomag volt egy adott EE JSR validálásához. Egyszerűen fogalmazva, Annak érdekében, hogy megfeleljen a Java EE-nek, egy alkalmazáskiszolgálónak végre kell hajtania az összes JSR-jét, és az összes tesztet le kell tennie a kijelölt TCK-n.

Itt nincs sok változás. Az Oracle nyílt forrásból szerezte a TCK-t, valamint az EE JSR-eket. Természetesen minden jövőbeli dokumentum és a TCK nyílt forráskódú lesz.

5. Következtetés

A Java EE bizonyosan sokat fejlődött ezekben az években. Örülök, hogy folyamatosan változik és javul.

Sok kihívás áll előttünk, reméljük tehát a zökkenőmentes átmenetet.