Po sześciu miesiącach prac rozwojowych firma Oracle wydała platformę Java SE 15 (Java Platform, Standard Edition 15), która jest używana jako wzorcowa implementacja w projekcie OpenJDK. W Java SE 15 zachowana jest kompatybilność wsteczna z wcześniejszymi wersjami platformy Java, wszystkie wcześniej napisane projekty Java będą działały bez zmian na nowej wersji. Gotowe do zainstalowania pakiety Java SE 15 (JDK, JRE i Server JRE) przygotowano dla systemów Linux (x86_64), Windows i macOS. Wzorcowa implementacja opracowana w ramach projektu OpenJDK Java 15 jest w pełni otwarta na licencji GPLv2 z wyjątkami GNU ClassPath, które umożliwiają dynamiczne łączenie z produktami komercyjnymi.

Java SE 15 należy do kategorii wydań o standardowym okresie wsparcia, aktualizacje będą wydawane do następnej wersji. Jako wersję z długoterminowym wsparciem (LTS) należy wykorzystać Java SE 11, aktualizacje będą wydawane do 2026 roku. Poprzednia gałąź LTS, Java 8, będzie wspierana do grudnia 2020 roku. Kolejne wydanie LTS planowane jest na wrzesień 2021 roku. Przypominamy, że od wydania Java 10 projekt przeszedł na nowy proces rozwoju, który zakłada krótszy cykl wydawania nowych wersji. Nowa funkcjonalność rozwija się teraz w jednej nieprzerwanie aktualizowanej gałęzi master, do której włączane są gotowe zmiany, a co sześć miesięcy powstają gałęzie stabilizujące nowe wydania.

Z nowości Java 15 można zaznaczyć:

• Wbudowana obsługa algorytmu tworzenia podpisu cyfrowego EdDSA (Edwards-Curve Digital Signature Algorithm RFC 8032). Proponowana implementacja EdDSA nie zależy od platform sprzętowych, jest odporna na ataki kanałami bocznymi (zapewnia stały czas wszystkich obliczeń) i pod względem wydajności przewyższa istniejącą implementację ECDSA, napisaną w języku C, przy tym samym poziomie ochrony. Na przykład EdDSA przy użyciu krzywej eliptycznej z kluczem 126-bitowym wykazuje wydajność porównywalną z ECDSA w przypadku krzywej eliptycznej secp256r1 i klucza 128-bitowego.
• Dodano eksperymentalne wsparcie dla zamkniętych („sealed”) klas i interfejsów, które nie mogą być używane przez inne klasy i interfejsy do dziedziczenia, rozszerzania lub nadpisywania implementacji. Zamknięte klasy oferują również bardziej deklaratywny sposób ograniczania użycia klasy bazowej niż modyfikatory dostępu, oparty na wyraźnym wymienieniu klas pochodnych do rozszerzenia.

  package com.example.geometry;

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

• Dodano wsparcie dla klas ukrytych, które nie mogą być używane bezpośrednio przez bajtkod innych klas. Kluczowym celem klas ukrytych jest użycie w frameworkach, które dynamicznie generują klasy w czasie wykonania i używają ich pośrednio przez refleksję.Takie klasy zazwyczaj mają ograniczony cykl życia, dlatego ich utrzymanie do dostępu z statycznie generowanych klas nie jest uzasadnione i tylko zwiększy zużycie pamięci. Klasy ukryte również umożliwiają obejście do niestandardowego API sun.misc.Unsafe::defineAnonymousClass, które ma być usunięte w przyszłości.
• Został ustabilizowany i uznany za gotowy do powszechnego użytku zbieracz śmieci ZGC (Z Garbage Collector). ZGC działa w pasywnym trybie, minimalizując opóźnienia spowodowane zbieraniem śmieci (czas zatrzymania przy użyciu ZGC nie przekracza 10 ms.) i może pracować zarówno z małymi, jak i ogromnymi stertami, od kilku setek megabajtów do wielu terabajtów.
• Został ustabilizowany i uznany za gotowy do powszechnego użytku
  zbieracz śmieci Shenandoah, działający z minimalnymi przestojami (Low-Pause-Time Garbage Collector). Shenandoah został opracowany przez firmę Red Hat i charakteryzuje się użyciem algorytmu, który skraca czas zatrzymania podczas zbierania śmieci, przeprowadzając czyszczenie równolegle z wykonywaniem aplikacji Java. Rozmiar opóźnień wprowadzanych przez zbieracz śmieci jest przewidywalny i nie zależy od rozmiaru sterty, tj. dla stert o wielkości 200 MB i 200 GB opóźnienia będą identyczne (nie przekraczają 50 ms i zwykle wynoszą 10 ms);
• Stabilizowano i wprowadzono do języka wsparcie bloków tekstowych — nowy typ literałów tekstowych, który umożliwia włączenie wielowierszowych danych tekstowych do kodu źródłowego bez potrzeby stosowania w nim sekwencji ucieczki, zachowując oryginalne formatowanie tekstu w bloku. Otoczenie bloku odbywa się za pomocą trzech podwójnych cudzysłowów.

  Na przykład, zamiast kodu

  String html = "<HTML>" +
  "\n\t" + "<BODY>" +
  „\n\t\t” + „

  „Java 15 is here!”

  ” +
  "\n\t" + "<\/BODY>" +
  "\n" + "<\/HTML>";

  można wskazać:

  String html = """
  <HTML>
  <BODY>
  

  „Java 15\
  jest dostępna!"<\/H1>
  <\/BODY>
  <\/HTML>""";

• Przeprojektowano API Legacy DatagramSocket. Stare implementacje java.net.DatagramSocket i java.net.MulticastSocket zostały zastąpione nowoczesną implementacją, która jest prostsza w debugowaniu i utrzymaniu oraz kompatybilna z wirtualnymi wątkami rozwijanymi w ramach projektu Loom. W przypadku możliwego naruszenia zgodności z istniejącym kodem, stara implementacja nie została usunięta i może być aktywowana za pomocą opcji jdk.net.usePlainDatagramSocketImpl.
• Zaproponowano drugą eksperymentalną implementację dopasowania wzoru w operatorze „instanceof”, który pozwala na natychmiastowe określenie lokalnej zmiennej do dostępu do zweryfikowanej wartości. Na przykład, można od razu napisać „if (obj instanceof String s && s.length() > 5) {.. s.contains(..) ..}” bez wyraźnego określania „String s = (String) obj”.

  Było:

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

  Teraz można obejść się bez definiowania „Group group = (Group) obj”:

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

• Zapewniono druga eksperymentalna implementacja słowa kluczowego „record„, które dostarcza kompaktowej formy do definiowania klas, pozwalającej na brak wyraźnego definiowania różnych niskopoziomowych metod, takich jak equals(), hashCode() i toString(), w przypadkach, gdy dane są przechowywane tylko w polach, a zachowanie pracy z nimi nie zmienia się. Gdy w klasie używane są typowe implementacje metod equals(), hashCode() i toString(), można obejść się bez ich wyraźnego definiowania:

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

  Ta deklaracja spowoduje automatyczne dodanie implementacji metod equals(), hashCode() i toString() w dodatku do konstruktora oraz metod zarządzających zmianą danych (getter).

• Zaproponowano drugi wstępny wariant API Foreign-Memory Access, umożliwiający aplikacjom Java bezpieczny i efektywny dostęp do obszarów pamięci poza stertą Java, manipulując nowymi abstrakcjami MemorySegment, MemoryAddress i MemoryLayout.
• Wyłączone i uznano za przestarzałą technikę optymalizacji Biased Locking, stosowaną w HotSpot JVM w celu zmniejszenia kosztów związanych z blokadami. Technika ta straciła znaczenie na systemach z atomowymi instrukcjami oferowanymi przez nowoczesne procesory i jest zbyt pracochłonna w utrzymaniu z powodu swojej złożoności.
• Ogłoszono przestarzałym mechanizm RMI Activation, który zostanie usunięty w jednym z kolejnych wydań. Zauważono, że RMI Activation stał się przestarzały, przesunięty w kategorię opcji już w Java 8 i prawie nie jest stosowany w nowoczesnej praktyce.
• Usunięto Silnik JavaScript Nashorn, który został ogłoszony przestarzałym w Java SE 11.
• Usunięto porty dla systemu operacyjnego Solaris i procesorów SPARC (Solaris/SPARC, Solaris/x64 i Linux/SPARC). Usunięcie tych portów pozwoli społeczności przyspieszyć rozwój nowych możliwości OpenJDK, nie tracąc czasu na utrzymanie funkcji specyficznych dla Solaris i SPARC.

Źródło: opennet.ru