Új Java 13 funkciók

1. Áttekintés

2019 szeptemberében megjelent a JDK 13, a Java új, hat hónapos kiadási üteménként. Ebben a cikkben áttekintjük az ebben a verzióban bevezetett új szolgáltatásokat és fejlesztéseket.

2. A fejlesztői szolgáltatások előnézete

A Java 13 két új nyelvi funkciót hozott magával, bár előnézeti módban. Ez azt jelenti, hogy ezeket a funkciókat a fejlesztők teljes mértékben kiértékelik, mégsem készek a gyártásra. Ezenkívül a visszajelzés alapján a jövőbeni kiadásokban eltávolíthatók vagy állandóvá tehetők.

Meg kell határoznunk –Engedhető-előnézet parancssori zászlóként az előnézeti funkciók használatához. Nézzük meg őket alaposan.

2.1. Switch Expressions (JEP 354)

Kezdetben a JDK 12-ben láttuk a kapcsolókifejezéseket. Java 13-as kapcsoló kifejezések az előző verzióra építenek egy új hozzáadásával hozam nyilatkozat.

Használata hozam, most már hatékonyan visszaadhatjuk az értékeket egy kapcsoló kifejezésből:

@Test @SuppressWarnings ("preview") public void whenSwitchingOnOperationSquareMe_thenWillReturnSquare () {var me = 4; var művelet = "squareMe"; var eredmény = kapcsoló (művelet) {eset "doubleMe" -> {hozam * 2; } case "squareMe" -> {hozd nekem * nekem; } alapértelmezett -> én; }; assertEquals (16, eredmény); }

Mint láthatjuk, most könnyű megvalósítani a stratégiai mintát az új használatával kapcsoló.

2.2. Szövegblokkok (JEP 355)

A második előnézeti funkció a többsoros szövegblokkok Húrpéldául beágyazott JSON, XML, HTML stb.

Korábban a JSON beágyazására a kódunkba azt deklaráltuk, hogy a Húr szó szerinti:

Karakterlánc JSON_STRING = "{\ r \ n" + "\" név \ ": \" Baeldung \ ", \ r \ n" + "\" website \ ": \" // www.% S.com / \ " \ r \ n "+"} ";

Most írjuk ugyanazt a JSON-t használva Húr szövegblokkok:

Karakterlánc TEXT_BLOCK_JSON = "" "{" name ":" Baeldung "," website ":" //www.%s.com/ "}" "";

Mint nyilvánvaló, nincs szükség a dupla idézőjelek elől vagy a visszatérő kocsi megadására. Szöveges blokkok használatával a beágyazott JSON sokkal egyszerűbb írni és könnyebben olvasható és karbantartható.

Sőt, minden Húr funkciók állnak rendelkezésre:

@Test public void whenTextBlocks_thenStringOperationsWorkSame () {assertThat (TEXT_BLOCK_JSON.contains ("Baeldung")). IsTrue (); assertThat (TEXT_BLOCK_JSON.indexOf ("www")). isGreaterThan (0); assertThat (TEXT_BLOCK_JSON.hossz ()). isGreaterThan (0); }

Is, java.lang.String most már három új módszer van a szövegblokkok kezelésére:

stripIndent () - utánozza a fordítót az esetleges térköz eltávolítására
translateEscapes () - lefordítja a menekülési szekvenciákat, mint pl „\ t” nak nek „\ T”
formázva () - ugyanúgy működik, mint String :: formátum, hanem szövegblokkokhoz

Vessünk egy gyors pillantást a Karakterlánc :: formázva példa:

assertThat (TEXT_BLOCK_JSON.formattált ("baeldung"). tartalmazza ("www.baeldung.com")). isTrue (); assertThat (String.format (JSON_STRING, "baeldung"). tartalmazza ("www.baeldung.com")). isTrue ();

Mivel a szövegblokkok előnézeti funkciók és egy későbbi kiadásban eltávolíthatók, ezek az új módszerek elavulásra vannak jelölve.

3. Dinamikus CDS-archívumok (JEP 350)

Az osztály adatmegosztás (CDS) egy ideje a Java HotSpot VM kiemelkedő jellemzője. Megengedi osztályú metaadatokat kell megosztani a különböző JVM-ek között az indítási idő és a memóriaterület csökkentése érdekében. A JDK 10 kibővítette ezt a lehetőséget az alkalmazás CDS (AppCDS) hozzáadásával - hogy a fejlesztőknek hatalmat adhassanak alkalmazásosztályok felvételére a megosztott archívumba. A JDK 12 tovább fejlesztette ezt a funkciót, és alapértelmezés szerint a CDS archívumokat is tartalmazza.

Az alkalmazásosztályok archiválásának folyamata azonban unalmas volt. Archív fájlok előállításához a fejlesztőknek próbafuttatásokat kellett végrehajtaniuk alkalmazásaikról, hogy előbb hozzanak létre osztálylistát, majd egy archívumba dobják. Ezt követően ezt az archívumot felhasználhatták a metaadatok megosztására a JVM-ek között.

Dinamikus archiválással a JDK 13 egyszerűsítette ezt a folyamatot. Most létrehozhatunk egy megosztott archívumot az alkalmazás kilépésekor. Ez feleslegessé tette a próbaüzemeket.

Ahhoz, hogy az alkalmazások dinamikus megosztott archívumot hozzanak létre az alapértelmezett rendszerarchívum tetején, hozzá kell adnunk egy lehetőséget -XX: ArchiveClassesAtExit és argumentumként adja meg az archívum nevét:

java -XX: ArchiveClassesAtExit = -cp AppName

Ezután az újonnan létrehozott archívum segítségével ugyanazt az alkalmazást futtathatjuk -XX: SharedArchiveFile választási lehetőség:

java -XX: SharedArchiveFile = -cp AppName

4. ZGC: Nem használt memória visszavonása (JEP 351)

A Z Garbage Collector a Java 11-ben alacsony késésű szemétgyűjtő mechanizmusként került bevezetésre, így a GC szünetideje soha nem haladta meg a 10 ms-ot. Más HotSpot VM GC-ktől, például a G1-től és a Shenandoah-tól eltérően azonban nem volt felkészülve arra, hogy a fel nem használt kupac memóriát visszaküldje az operációs rendszerbe. A Java 13 hozzáadta ezt a képességet a ZGC-hez.

Csökkentett memóriaterületet kapunk a teljesítmény javításával együtt.

A Java 13-tól kezdve a A ZGC most alapértelmezés szerint visszaadja a lekötetlen memóriát az operációs rendszernek, amíg a megadott minimális kupacméretet el nem érik. Ha nem akarjuk használni ezt a funkciót, akkor visszatérhetünk a Java 11-re:

Az opció használata -XX: -ZUncommit, vagy
Egyenlő minimum beállítása (-Xms) és maximum (-Xmx) kupacméretek

Ezenkívül a ZGC maximális támogatott kupacmérete 16 TB. Korábban a 4 TB volt a határ.

5. Tegye vissza a Legacy Socket API-t (JEP 353)

Láttuk a Socket-et (java.net.Socket és java.net.ServerSocket) Az API-k a Java szerves részeként annak kezdete óta. Az elmúlt húsz évben azonban soha nem modernizálták őket. A régi Java-ban és C-ben írva nehézkesek és nehezen karbantarthatók voltak.

A Java 13 visszatükrözte ezt a trendet, és felváltotta az alapul szolgáló megvalósítást, hogy az API-t a futurisztikus felhasználói módú szálakhoz igazítsa. Ahelyett PlainSocketImpl, a szolgáltatói felület most rámutat NioSocketImpl. Ez az újonnan kódolt megvalósítás ugyanazon a belső infrastruktúrán alapul, mint a java.nio.

Ismét van módunk visszatérni a használatra PlainSocketImpl. A JVM-et a rendszer tulajdonsággal tudjuk elindítani -Djdk.net.usePlainSocketImpl beállítva igaz a régebbi megvalósítás használatához. Az alapértelmezett NioSocketImpl.

6. Egyéb változások

A fent felsorolt JEP-eken kívül a Java 13 még néhány figyelemre méltó változást adott nekünk:

java.nio - módszer FileSystems.newFileSystem (elérési út, térkép) - tette hozzá
java.time - új hivatalos japán kori név került hozzáadásra
javax.crypto - az MS Cryptography Next Generation (CNG) támogatása
javax.biztonság - ingatlan jdk.sasl.disabledMechanizmusok hozzáadva a SASL mechanizmusok letiltásához
javax.xml.crypto - új Húr a Canonical XML 1.1 URI-kat ábrázoló állandók
javax.xml.parsers - új módszerek hozzáadva a DOM és SAX gyárak névterek támogatásával történő példányosításához
Unicode támogatás frissítve a 12.1 verzióra
Támogatás hozzáadva a Kerberos fő nevének kanonizálásához és keresztirányú hivatkozásokhoz

Ezenkívül néhány API-t javasolnak eltávolítani. Ide tartozik a három Húr a fent felsorolt módszerek és javax.biztonság.cert API.

Az eltávolítások közé tartozik a rmic eszköz és a JavaDoc eszköz régi funkciói. JDK előtti 1.4 SocketImpl a megvalósításokat szintén nem támogatják.

7. Következtetés

Ebben a cikkben mind az öt JDK Enhancement javaslatot láttuk, amelyet a Java 13 hajtott végre. Néhány további figyelemre méltó kiegészítést és törlést is felsoroltunk.

Szokás szerint a forráskód elérhető a GitHubon.

streamalism.org