streamalism.org

1. Bemutatkozás

Ebben a cikkben megvitatjuk a Java új, időalapú kiadásait és azok minden típusú fejlesztőkre gyakorolt ​​hatását.

A kiadási ütemterv módosítása magában foglalja a Java-verziók szolgáltatás-kézbesítési és támogatási szintjének frissítését. Összességében ezek a változások egyértelműen különböznek a Java-tól, amelyet az Oracle 2010 óta támogat.

2. Miért hat hónapos kiadások?

Azok számára, akik hozzászoktak a Java történelmileg lassú kiadási üteméhez, ez elég jelentős eltérés. Miért ilyen drámai változás?

Eredetileg a Java a nagy verziók bevezetése körül határozta meg főbb kiadásait. Ez hajlamos volt késéseket okozni, mint amilyeneket mindannyian a Java 8 és 9 esetében tapasztaltunk. Ez is lelassította a nyelvi innovációt, míg más szigorúbb visszacsatolási ciklusú nyelvek fejlődtek.

Egyszerűen fogalmazva, a rövidebb kiadási időszakok kisebb, könnyebben kezelhető előrelépésekhez vezetnek. A kisebb funkciókat pedig könnyebben átveheti.

Egy ilyen minta jól párosul a jelenlegi körülmények között, és lehetővé teszi, hogy a JDK fejlesztése agilis módszertanokban működjön, hasonlóan az általa támogatott közösséghez. Ezenkívül versenyképesebbé teszi a Java-t olyan futási idővel, mint a NodeJS és a Python.

Természetesen a lassabb ütemnek is megvannak az előnyei, és így a hat hónapos kiadási ciklus egy nagyobb Hosszú távú támogatási keretben is szerepet játszik, amelyet a 4. szakaszban vizsgálunk meg.

3. Verziószám módosítása

Ennek a változásnak egy mechanikus aspektusa egy új verziószám-séma.

3.1. JEP 223 verzió-sztring séma

Mindannyian ismerjük a régit, amelyet a JEP 223 kódol. Ez a séma a verziószámokat növekményessé tette, és további információkat továbbított.

 A tényleges hipotetikus verzió hosszú, rövid ------------ ------------------------ Biztonság 2013/06 1.7.0_25- b15 7u25 Minor 2013/09 1.7.0_40-b43 7u40 Security 2013/10 1.7.0_45-b18 7u45 Security 2014/01 1.7.0_51-b13 7u51 Minor 2014/05 1.7.0_60-b19 7u60

Ha futunk java -verzió a 8-as vagy annál régebbi JVM-en valami ilyesmit fogunk látni:

> java -verzió java verzió "1.6.0_27" Java (TM) 2 Runtime Environment, Standard Edition (1.6.0_27-b07 build) Java HotSpot (TM) Client VM (1.6.0_27-b13 build, vegyes mód, megosztás)

Ebben az esetben feltételezhetjük, hogy ez a Java 6-ra vonatkozik, ami helyes, és a 27. frissítésre, ami hibás. A számozási séma nem annyira intuitív, mint amilyennek látszik.

A kisebb kiadások 10-szeresei voltak, és a biztonsági kiadások minden mást kitöltöttek. Általában azt látnánk, hogy a rövid húr a helyi telepítéseinkhez van csatolva, mint pl JDK 1.8u174. A következő kiadás lehet JDK 1.8u180, ami kisebb javításokkal járna.

3.2. Új verzió-karakterlánc séma

Az új verzió-karakterlánc sémaa verziószámok átdolgozása, hogy ne a kompatibilitást és a jelentőséget kódolja, hanem az idő múlását a kiadási ciklusok szempontjából,”- írja Mark Reinhold a JEP-ben.

Vessünk egy pillantást néhányra:

9.0.4 11.0.2 10.0.1

Rövid pillantásra ez szemantikai változatnak tűnik; ez azonban nem így van.

A szemantikus verzióval a tipikus szerkezet az $ MAJOR. $ MINOR. $ PATCH, de a Java új verziószerkezete a következő:

$ FEATURE. $ INTERIM. $ UPDATE. $ PATCH

$ FEATURE ezt gondolhatjuk fő verziónak, de félévente növekszik, a kompatibilitási garanciáktól függetlenül. És $ PATCH karbantartási kiadásokra szól. De itt megállnak a hasonlóságok

Első, $ IDŐKÖZI helyőrző, az Oracle fenntartotta a jövő igényeire. Egyelőre mindig nulla lesz.

És másodszor, $ UPDATE időalapú, mint $ FEATURE, havonta frissítve a legújabb funkció kiadás után.

És végül a záró nullákat csonkolják.

Ez azt jelenti 11 a Java 11 kiadási száma, amely 2018 szeptemberében jelent meg, 11.0.1 az első havi frissítéskiadása októberben, és 11.0.1.3 hipotetikus harmadik patch kiadás lenne az októberi verziótól.

4. Több verzió elosztás

Ezután nézzük meg, hogyan lehet kiválasztani a megfelelő verziót.

4.1. Stabilitás

Egyszerűen fogalmazva: a Java mostantól félévente gyors és háromévente lassú csatornával rendelkezik.Minden harmadik éves kiadást LTS kiadásnak nevezünk.

A gyors csatornán a nyelv inkubációs funkciókat bocsát ki. Ezek a nyelvi jellemzők stabilizálódnak az LTS kiadásban.

Tehát azoknak a vállalatoknak, akik képesek felfogni a volatilitást az új szolgáltatások használatáért cserébe, használhatják a gyors csatornát. Azoknál a vállalkozásoknál, amelyek értékelik a stabilitást és várják a frissítést, minden LTS kiadáskor frissíthetnek.

A JDK verziókkal történő kísérletezés lehetővé teszi a fejlesztők számára a legjobb illeszkedés megtalálását.

4.2. Támogatás

Természetesen itt van a támogatás kérdése is. Most, hogy a Java 8 támogatás lejárt, mit tegyünk?

És ahogy azt korábban megbeszéltük, a válasz LTS verziókban érkezik, A Java 11 a legújabb LTS kiadás, a 17 pedig a következő. A frissítéseket olyan gyártók fogják elérni és támogatni, mint az Oracle és az Azul.

Ha megbízhatunk a közösség támogatásában, akkor a Redhat, az IBM és mások kijelentették, hogy támogatják az OpenJDK hibajavításait. Az AdoptOpenJDK projekt előre elkészített bináris fájlokat is biztosít az OpenJDK számára.

4.3. Engedélyezés

Egyesek számára az egyik zavart az OpenJDK és az Oracle JDK közötti különbség.

Valójában közel azonosak, csak abban különböznek egymástól, hogy mely hibajavításokat és biztonsági javításokat vették fel Brian Goetz szerint.

Az OpenJDK a legtöbb származtatott JDK forrásaként működik, és szabad marad. A Java 11-től kezdve az Oracle kereskedelmi licencdíjakat számít fel az Oracle JDK-ért, további támogatással és szolgáltatásokkal együtt.

4.4. Töredezettség

Gyakoribb kiadások esetén a széttagoltság kérdéssé válhat. Hipotetikus szempontból mindenki a Java különböző verzióin futtathat, különböző funkciókkal, a mostaninál is jobban.

Természetesen a konténerezés segíthet ennek kezelésében. A Dockertől és a CoreOS-tól a Red Hat OpenShiftjéig a konténerezés biztosítja a szükséges szigetelést, és már nem kényszeríti a Java egyetlen telepítési helyét a kiszolgálón való használatra.

5. Következtetés

Összegzésként elmondhatjuk, hogy sokkal többet várhatunk az Oracle Java csapatától a Java rendszeres félévenkénti kiadásával. Java fejlesztőként izgalmas a félévenkénti új nyelvi funkciók lehetősége.

Tartsuk szem előtt néhány következményt, amikor eldöntjük, mi a frissítési csatornánk, ha támogatásra és licencre van szükségünk, és hogyan kezeljük a széttöredezettséget.