JDK 15: Nowe funkcje w Javie 15

Java Development Kit 15, implementacja przez Oracle następnej wersji Java SE (Standard Edition), staje się dostępna jako wydanie produkcyjne dzisiaj, 15 września 2020 r. Najważniejsze cechy JDK 15 obejmują bloki tekstowe, ukryte klasy, API dostępu do pamięci obcej, Z Garbage Collector oraz podglądy zapieczętowanych klas, dopasowywania wzorców i rekordów.

JDK 15 to tylko wersja krótkoterminowa, która ma być obsługiwana tylko przez Oracle Premier Support przez sześć miesięcy, aż do JDK 16 pojawi się w marcu przyszłego roku. JDK 17, następna wersja długoterminowego wsparcia technicznego, która będzie obsługiwana przez Oracle przez osiem lat, ma pojawić się za rok od teraz, zgodnie z sześciomiesięcznym cyklem wydawania wersji Java SE przez Oracle.

Programiści mogą teraz przyjrzeć się JDK 15, aby zorientować się, co będzie w JDK 17, powiedział Georges Saab, prezes Oracle Java Platform Group. Aktualną wersją LTS jest JDK 11, która pojawiła się we wrześniu 2018 r. Wydania LTS pojawiają się co trzy lata. JDK 15 następuje po JDK 14, który został wydany 17 marca 2020 r. 

Nowe funkcje i zmiany w OpenJDK 15:

  • Drugi inkubator interfejsu API dostępu do pamięci obcej, który umożliwiałby programom Java bezpieczny i wydajny dostęp do pamięci obcej poza stertą Java. Interfejs API powinien mieć możliwość działania na różnych rodzajach pamięci obcej, takich jak sterta natywna, trwała i zarządzana. Wiele programów Java korzysta z pamięci obcej, takich jak Ignite i MapDB. Interfejs API pomógłby uniknąć kosztów i nieprzewidywalności związanych z wyrzucaniem elementów bezużytecznych, współużytkować pamięć między procesami oraz serializować i deserializować zawartość pamięci przez mapowanie plików do pamięci. Interfejs API języka Java nie zapewnia obecnie zadowalającego rozwiązania w zakresie dostępu do pamięci obcej. Jednak dzięki nowej propozycji API nie powinno mieć możliwości podważania bezpieczeństwa JVM. Ta zdolność przechodzi wcześniejszą fazę inkubatora w JDK 14, z udoskonaleniami oferowanymi w JDK 15. 
  • Podgląd zapieczętowanych klas. Wraz z interfejsami, zapieczętowane klasy ograniczają, które inne klasy lub interfejsy mogą je rozszerzać lub implementować. Cele tej funkcji obejmują pozwolenie autorowi klasy lub interfejsu na kontrolowanie, który kod jest odpowiedzialny za jego implementację, zapewnienie bardziej deklaratywnego sposobu niż modyfikatory dostępu w celu ograniczenia użycia nadklasy oraz wspieranie przyszłych kierunków w dopasowywaniu wzorców poprzez wspieranie wyczerpującego analiza wzorców.
  • Usunięcie kodu źródłowego i wsparcie kompilacji dla portów Solaris / SPARC, Solaris / x64 i Linux / SPARC, które zostały uznane za przestarzałe do usunięcia w JDK 14 z zamiarem usunięcia ich w przyszłej wersji. Wiele projektów i funkcji w fazie rozwoju, takich jak Valhalla, Loom i Panama, wymaga znaczących zmian w architekturze procesora i kodzie specyficznym dla systemu operacyjnego. Rezygnacja ze wsparcia dla portów Solaris i SPARC umożliwi współtwórcom społeczności OpenJDK przyspieszenie rozwoju nowych funkcji, które posuną platformę do przodu. Zarówno Solaris, jak i SPARC zostały w ostatnich latach zastąpione przez system operacyjny Linux i procesory Intel.
  • Rekordy, które są klasami, które działają jako przezroczyste nośniki niezmiennych danych, zostałyby uwzględnione w drugiej wersji zapoznawczej w JDK 15, po debiucie jako wczesna wersja zapoznawcza w JDK 14. Cele planu obejmują opracowanie konstrukcji zorientowanej obiektowo, która wyraża prosta agregacja wartości, pomagająca programistom skupić się na modelowaniu niezmiennych danych zamiast rozszerzalnych zachowań, automatycznym wdrażaniu metod opartych na danych, takich jak równość i oceniający, oraz zachowaniu długoletnich zasad Javy, takich jak typowanie nominalne i zgodność migracji. Rekordy można traktować jako nominalne krotki. 
  • Podpisy kryptograficzne oparte na algorytmie podpisu cyfrowego Edwards-Curve (EdDSA). EdDSA to nowoczesny schemat krzywych eliptycznych, który ma przewagę nad istniejącymi schematami sygnatur w JDK. EdDSA zostanie wdrożone tylko u dostawcy SunEC. EdDSA jest poszukiwany ze względu na jego lepsze bezpieczeństwo i wydajność w porównaniu z innymi schematami podpisów; jest już obsługiwany w bibliotekach kryptograficznych, takich jak OpenSSL i BoringSSL.
  • Reimplementing API Legacy DatagramSocket poprzez zastąpienie podstawowych implementacji  java.net.datagram.Socketi java.net.MulticastSocketAPI z prostszych i bardziej nowoczesnych wdrożeń że 1. są łatwe do debugowania i utrzymania oraz 2. Praca z wirtualnymi wątków obecnie badane w projekcie Loom. Nowy plan jest kontynuacją propozycji JDK Enhancement 353, która ponownie zaimplementowała starszą wersję Socket API. Obecne implementacje java.net.datagram.Socketi java.net.MulticastSocketsięgają wstecz do JDK 1.0 oraz czasów, kiedy IPv6 był jeszcze w fazie rozwoju. Stąd obecna implementacja  MulticastSocket próbuje pogodzić IPv4 i IPv6 w sposób trudny do utrzymania.
  • Wyłączenie domyślnego blokowania stronniczego i wycofanie wszystkich powiązanych opcji wiersza polecenia. Celem jest określenie potrzeby dalszego wspierania kosztownej w utrzymaniu optymalizacji synchronizacji ze starszymi wersjami, która jest wykorzystywana w maszynie wirtualnej HotSpot w celu zmniejszenia kosztów związanych z niezakończonym blokowaniem. Chociaż w niektórych aplikacjach Java może wystąpić regresja wydajności przy wyłączonym blokowaniu stronniczości, wzrost wydajności wynikający z blokowania stronniczego jest na ogół mniej oczywisty niż kiedyś.
  • Drugi podgląd dopasowania wzorców dla instanceof, po poprzednim w JDK 14. Dopasowywanie wzorców pozwala na łatwiejsze i bardziej zwięzłe wyrażenie wspólnej logiki w programie, głównie warunkowej ekstrakcji komponentów z obiektów. Języki, takie jak Haskell i C #, objęły dopasowywanie wzorców ze względu na zwięzłość i bezpieczeństwo.
  • Klasy ukryte, tj. Klasy, które nie mogą być używane bezpośrednio przez kod bajtowy innych klas, są przeznaczone do użycia przez frameworki, które generują klasy w czasie wykonywania i używają ich pośrednio poprzez odbicie. Ukrytą klasę można zdefiniować jako element członkowski gniazda kontroli dostępu i można ją usunąć niezależnie od innych klas. Propozycja poprawiłaby wydajność wszystkich języków w JVM poprzez umożliwienie standardowemu API definiowania ukrytych klas, które nie są wykrywalne i mają ograniczony cykl życia. Struktury wewnątrz i na zewnątrz JDK byłyby w stanie dynamicznie generować klasy, które mogłyby zamiast tego definiować klasy ukryte. Wiele języków zbudowanych na JVM polega na dynamicznym generowaniu klas w celu zapewnienia elastyczności i wydajności. Cele tej propozycji obejmują: umożliwienie ramom definiowania klas jako niewykrywalnych szczegółów implementacji struktury,więc nie mogą być łączone przez inne klasy ani odkrywane przez refleksję; obsługa rozszerzania gniazda kontroli dostępu o niewykrywalne klasy; i wsparcie dla agresywnego zwalniania klas, których nie można wykryć, więc frameworki mają elastyczność definiowania tylu, ile potrzeba. Kolejnym celem jest wycofanie niestandardowego interfejsu API, misc.Unsafe::defineAnonymousClass, z zamiarem wycofania z użycia w celu usunięcia w przyszłej wersji. Ponadto w wyniku tej propozycji nie należy zmieniać języka Java.
  • Z Garbage Collector (ZGC) przechodzi od funkcji eksperymentalnej do produktu w ramach tej propozycji. Zintegrowany z JDK 11, który pojawił się we wrześniu 2018 r., ZGC to skalowalny moduł zbierający elementy bez opóźnień. ZGC został wprowadzony jako funkcja eksperymentalna, ponieważ programiści Javy zdecydowali, że cecha tej wielkości i złożoności powinna być wprowadzana ostrożnie i stopniowo. Od tego czasu dodano szereg ulepszeń, począwszy od równoczesnego wyładowywania klas, niezatwierdzania nieużywanej pamięci i obsługi udostępniania danych klas, po ulepszoną świadomość NUMA i wielowątkowe wstępne dotknięcie sterty. Zwiększono również maksymalny rozmiar sterty z czterech do 16 terabajtów. ZGC rozwiązuje problemy z wydajnością w aplikacjach, które obejmują ogromne ilości danych, takich jak uczenie maszynowe,gdzie użytkownicy chcą mieć pewność, że przetwarzanie danych nie będzie narażone na nieprzewidywalność lub długie przerwy z powodu czyszczenia pamięci. Obsługiwane platformy obejmują Linux, Windows i MacOS.
  • Bloki tekstowe, których podgląd jest wyświetlany zarówno w JDK 14, jak i JDK 13, mają uprościć pisanie programów w języku Java, ułatwiając wyrażanie ciągów obejmujących kilka wierszy kodu źródłowego, unikając w typowych przypadkach sekwencji specjalnych. Blok tekstowy to wieloliniowy literał ciągu, który pozwala uniknąć większości sekwencji sterujących, automatycznie formatuje ciąg w przewidywalny sposób i oferuje deweloperowi kontrolę nad formatem w razie potrzeby. Celem propozycji bloków tekstowych jest zwiększenie czytelności ciągów znaków w programach Java, które oznaczają kod napisany w językach innych niż Java. Innym celem jest wsparcie migracji z literałów łańcuchowych poprzez zastrzeżenie, że każda nowa konstrukcja może wyrażać ten sam zestaw ciągów co literał ciągu, interpretować te same sekwencje ucieczki i być manipulowana w ten sam sposób, co literał ciągu.Programiści OpenJDK mają nadzieję dodać sekwencje ucieczki, aby zarządzać jawnymi białymi znakami i kontrolą nowego wiersza.
  • Śmieciarka Shenandoah o niskiej przerwie stałaby się elementem produkcyjnym i wyszłaby z etapu eksperymentalnego. Został zintegrowany z JDK 12 rok temu.
  • Usunięcie Nashorna, który zadebiutował w JDK 8 w marcu 2014 roku, ale od tego czasu stał się przestarzały przez technologie takie jak GraalVM. Propozycja OpenJDK 15 wzywa do usunięcia interfejsów API Nashorn i narzędzia wiersza poleceń jjs używanego do wywoływania Nashorn.
  • Wycofanie mechanizmu aktywacji RMI do przyszłego usunięcia. Mechanizm aktywacji RMI jest przestarzałą częścią RMI, która jest opcjonalna od czasu Java 8. Aktywacja RMI nakłada ciągłe obciążenie konserwacyjne. Żadna inna część RMI nie zostanie wycofana.