Hat hónapnyi fejlesztés után az Oracle cég kiadta platformját Java SE 15 (Java Platform, Standard Edition 15), amelynek referenciakivitelezése az OpenJDK nyílt forráskódú projekt. A Java SE 15 megőrzi a visszafelé kompatibilitást a Java platform korábbi verzióival, így a már meglévő Java-projektek változtatás nélkül futtathatók az új verzióval. A Java SE 15 (JDK, JRE és Server JRE) telepítésre kész kiadásai kiadások elérhetők Linuxra (x86_64), Windowsra és macOS-ra. Az OpenJDK projekt keretein belül kifejlesztett referenciaimplementáció Java 15 teljes mértékben nyílt, GPLv2 licenc alatt, GNU ClassPath kivételekkel, amelyek lehetővé teszik a dinamikus kötést kereskedelmi termékekkel.

A Java SE 15 a szokásos támogatási időszakú kiadások közé tartozik, a frissítések a következő verzióig fognak megjelenni. Hosszú távú támogatásra (LTS) a Java SE 11-et kell használni, amelynek frissítései 2026-ig fognak megjelenni. A korábbi LTS-kiadás, a Java 8, 2020 decemberéig lesz támogatott. A következő LTS-kiadás várhatóan 2021 szeptemberében érkezik. Emlékeztetünk rá, hogy a Java 10 kiadással a projekt új fejlesztési folyamatra váltott, amely egy rövidebb új kiadási ciklust jelöl ki. Az új funkcionalitás egy folyamatosan frissített master-ágban fejlődik, amely már kész változtatásokat tartalmaz, és amelyből hat havonta új ágakat elágaztatnak a stabil új kiadásokhoz.

A újdonságok Java 15 lehetővé teszi a szándékot:

• Beépített a digitális aláírás generálásának EdDSA (Edwards-Curve Digitális Aláírási Algoritmus) támogatása RFC 8032). Az EdDSA által javasolt megvalósítás nem függ az hardver platformoktól, védi a külső csatornákból érkező támadásoktól (minden számítás időpontja állandó) és teljesítményben felülmúlja a meglévő ECDSA megvalósítást, amely C nyelven készült, azonos védelmi szinten. Például az EdDSA, 126 bites kulcs használatával elliptikus görbével, hasonló teljesítményt mutat az ECDSA-hoz, amely a secp256r1 elliptikus görbével és 128 bites kulccsal működik.
• Hozzáadva kísérleti támogatás a lezárva („sealed”) osztályok és interfészek számára, amelyek más osztályok és interfészek nem használhatják öröklésre, kibővítésre vagy megvalósítás felülbírálására. A lezárt osztályok deklaratívabb módot kínálnak a szülőosztály használatának korlátozására, mint a hozzáférési módosítók, a származtatott osztályok expliciteni felsorolásán alapulva, amelyek kibővítésére engedélyezettek.

  package com.example.geometry;

  public sealed class Shape
  permits com.example.polar.Circle,
  com.example.quad.Rectangle,
  com.example.quad.simple.Square {…}

• Hozzáadva támogatás rejtett osztályokhoz, amelyeket nem lehet közvetlenül bytekód által más osztályok használni. A rejtett osztályok kulcsfontosságú célja, hogy keretrendszerekben használják őket, amelyek dinamikusan generálnak osztályokat futásidőben, és közvetve használják őket, a reflektálás. Az ilyen osztályok általában korlátozott élettartammal rendelkeznek, ezért a statikusan generált osztályokból való hozzáférésük fenntartása nem indokolt, és csak a memóriafogyasztás növekedéséhez vezet. A rejtett osztályok lehetővé teszik a sun.misc.Unsafe::defineAnonymousClass nem szabványos API elkerülését is, amelyet a jövőben el fognak távolítani.
• Stabilizálva lett és készen áll a széleskörű használatra a ZGC (Z Garbage Collector) szeméttisztító. A ZGC passzív módon működik, amennyire csak lehetséges, minimalizálva a szemétgyűjtés miatti késleltetéseket (a ZGC használatakor a leállási idő nem haladja meg a 10 ms-ot), és képes dolgozni kis és hatalmas kupacokkal is, amelyek mérete több száz megabájttól több terabájtig terjed.
• Stabilizálva lett és készen áll a széleskörű használatra
  szeméttisztító Shenandoah, amely minimális leállásokkal működik (Low-Pause-Time Garbage Collector). A Shenandoah-t a Red Hat fejlesztette ki, és jellemzi az a algoritmus, amely csökkenti a szemétgyűjtés közben fellépő leállások idejét, azáltal, hogy párhuzamosan végez takarítást a Java alkalmazások futtatásával. A szeméttisztító által okozott késleltetések előreláthatóak és nem függenek a kupac méretétől, azaz ha a kupac 200 MB vagy 200 GB, a késleltetés azonos lesz (nem lépi túl a 50 ms-ot és általában 10 ms-on belül van);
• Stabilizálva lett és belekerült a nyelvbe a támogatás szöveges blokkokhoz — az új formai karakterlánc-irodalmak, amelyek lehetővé teszik többsoros szöveges adatok beillesztését a forrásszövegbe anélkül, hogy szimbólumokat kellene escape-elni és megőrizve a szövege blokkban lévő eredeti formázást. A blokk határolása három duplakötőjellel történik.

  Például a következő kód helyett

  String html = «<HTML>» +
  «\n\t» + «<BODY>» +
  «\n\t\t» + «

  "Java 15 is here!"

  » +
  «\n\t» + «<\/BODY>» +
  «\n» + «<\/HTML>»;

  lehet megadni:

  String html = «»»
  <HTML>
  <BODY>
  

  "Java 15\
  itt van!»<\/H1>
  <\/BODY>
  <\/HTML>»»»;

• Átdolgozásra került API Legacy DatagramSocket. A régi java.net.DatagramSocket és java.net.MulticastSocket implementációkat modern, könnyebben hibakereshető és karbantartható megoldással helyettesítették, amely kompatibilis a Loom projekt keretében fejlesztett virtuális szálakkal. Loom. A meglévő kódokkal való esetleges kompatibilitási problémák elkerülése érdekében a régi megvalósítás nem került eltávolításra, és aktiválható a jdk.net.usePlainDatagramSocketImpl opcióval.
• Javasolták a második kísérleti megvalósítást mintázathoz való illesztés az "instanceof" operátorban, amely lehetővé teszi egy helyi változó azonnali meghatározását a vizsgált értékhez való hivatkozásra. Például közvetlenül írhatjuk, hogy "if (obj instanceof String s && s.length() > 5) {.. s.contains(..) ..}" anélkül, hogy kifejezetten definiálnánk "String s = (String) obj".

  Régebben:

  if (obj instanceof Group) {
  Group group = (Group) obj;
  var entries = group.getEntries();
  }

  Most már elkerülhetjük a "Group group = (Group) obj" meghatározását:

  if (obj instanceof Group group) {
  var entries = group.getEntries();
  }

• Javasolt a második kísérleti megvalósítása a „record" kulcsszóhoz», amely kompakt formát biztosít az osztályok meghatározásához, lehetővé téve a különböző alacsony szintű metódusok, mint az equals(), hashCode() és toString() kifejezett definiálása nélküli használatot, amikor az adatok csak mezőkben tárolódnak, és a műveletek viselkedése nem változik. Amikor az osztályban a metódusok típuskivitelezései, mint az equals(), hashCode() és toString() használatban vannak, akkor ezek kifejezett definiálása nélkül is működhet az osztály:

  public record BankTransaction(LocalDate date,
  double amount,
  String description) {}

  Ez a hirdetés automatikus módon hozzáadja az equals(), hashCode() és toString() metódusok megvalósítását a konstruktorhoz és az adatmódosítást vezérlő metódusokhoz (getter).

• Ajánlott a második előzetes változata az API Foreign-Memory Access, amely lehetővé teszi a Java-alkalmazások számára, hogy biztonságosan és hatékonyan hozzáférjenek a Java halon kívüli memória területekhez, új MemorySegment, MemoryAddress és MemoryLayout absztrakciók kezelésével.
• Kikapcsolva és elavultnak nyilvánították azt az Biased Locking optimalizálási technikát, amelyet a HotSpot JVM használt a zárolások költségeinek csökkentésére. Ez a technika elvesztette relevanciáját az atomikus utasításokkal rendelkező modern CPU-ken, és túl munkaigényes a fenntartásához a bonyolultsága miatt.
• Kihirdették elavult mechanizmusként RMI Activation, amelyet a következő kiadások egyikében eltávolítanak. Megjegyzik, hogy a RMI Activation elavult, már a Java 8-ban opcióvá vált, és a modern gyakorlatban szinte nem használják.
• Törölve JavaScript-motor Nashorn, amelyet a Java SE 11-ben elavultnak nyilvánítottak.
• Eltávolítva Solaris operációs rendszerhez és SPARC processzorokhoz készült portok (Solaris/SPARC, Solaris/x64 és Linux/SPARC). Az említett portok eltávolítása lehetővé teszi a közösség számára, hogy felgyorsítsa az OpenJDK új lehetőségeinek fejlesztését anélkül, hogy időt pazarolna a Solaris és SPARC specifikus jellemzőinek fenntartására.

Forrás: opennet.ru