Java 15 - co nowego?

Twórcy Javy wydali właśnie nową wersję swojej technologii. Poznaj listę nowych funkcji, które znalazły się w wydaniu Java 15.

Jak co pół roku dostajemy w nasze ręce nową wersję Javy. Java 15 jest kolejnym wydaniem nie-LTS, co oznacza, że będzie mieć wsparcie przez kolejne pół roku. Co więc przynosi Java 15? Przyjrzyjmy się wszystkim nowościom.

Bloki tekstu

W dwóch poprzednich wersjach funkcja ta znajdowała się w fazie preview. Teraz jest domyślnie włączona (JEP 378). Bloki tekstu oferują programistom możliwość tworzenia wielolinijkowych literałów, w których nie trzeba używać znaków ucieczki, aby sformatować tekst. Bloki tekstu będą zawierać się między znakami """

W praktyce wygląda to tak:

String html = """
              <html>
                  <body>
                      <p>Hello, world</p>
                  </body>
              </html>
              """;

Co będzie przechowywać następujący tekst:

<html>
    <body>
        <p>Hello, world</p>
    </body>
</html>

Klasy ukryte i zapieczętowane

W Javie 15 pojawia się pojęcie ukrytej klasy, czyli klasy, która nie może zostać użyta wprost przez kod bajtowy innej klasy. Nie znaczy to, że taki kod nie może zostać wykorzystany w ogóle. Klasy ukryte można będzie użyć poprzez refleksję. Cały mechanizm ma w założeniu być używany przez frameworki, które tworzą klasy w czasie wykonania. Funkcja ta nie wprowadza zmian w języku jako takim, a jedynie rozszerza Lookup API o metodę Lookup::defineHiddenClass. Nie jest to nowość, która będzie szeroko używana w codziennym programowaniu, ale jeżeli wydaje Ci się to interesujące, to warto przyjrzeć się opisowi z JEP 371.

Kolejną nowością, tym razem preview, są klasy zapieczętowane (JEP 360). Takie klasy i interfejsy pozwolą ograniczyć, jakie inne klasy lub interfejsy mogą je rozszerzyć (lub implementować). Tak naprawdę chodzi o to, by autor kodu miał kontrolę nad tym, gdzie powinna znajdować się odpowiedzialność za implementację i dodatkowo mógł ograniczyć używanie nadklas. Nowa funkcja wprowadza zmiany w języku, w dokumentacji JEP-a znajdziemy taki przykład:

package com.example.geometry;

public abstract sealed class Shape
    permits Circle, Rectangle, Square {...}

Dodanie słowa kluczowego sealed i następnie permits ograniczy możliwości rozszerzania klasy Shape do wymienionych niżej klas Circle, Rectangle, Square. Klasy wymienione w permits muszą znajdować się w tym samym module lub pakiecie (jeżeli znajdują się w nienazwanym module).

Dodatkowo w każdej z wylistowanych w permits klas trzeba zadbać o jasne reguły dla kolejnych podklas. Są tu 3 opcje oznaczania takich klas:

- final, co kończy problem dziedziczenia
- sealed, co kontynuuje temat
- non-sealed, co zdejmuje dalsze ograniczenia w tworzeniu hierarchii klas.

Podobnie sprawa wygląda dla interfejsów.

Kolejna iteracja preview — rekordy i dopasowanie do wzorca

Do Javy 15 trafiły dwie funkcje, które są oznaczone jako „second preview” - Rekordy (JEP 384) i pattern matching for instanceof (JEP 375). O obydwu nowościach i ich podstawowych możliwościach pisałem w dniu premiery Javy 14.

Rekordy to skrócona notacja dla klas, które służą jako niemutowalne kontenery danych. W wersji 15 rozwinięto integrację nowej funkcji z innymi koncepcjami języka. Dodano możliwość tworzenia lokalnych rekordów, podobnie jak to można robić z klasami lokalnymi. Rekordów można też już używać z interfejsami zapieczętowanymi — pewnym ułatwieniem jest tutaj to, że rekordy są pod spodem definiowane jako „final”, co oszczędza parę kliknięć w klawiaturę. Kolejne ulepszenia obejmują również dodanie metod do Reflection API, które pozwolą na obsługę rekordów.

Dopasowanie do wzorca z instanceof w przyszłości stanie się jednym z centralnych konceptów w języku, co wnioskuję po liczbie JEP-ów, które wspominają o wykorzystaniu tej funkcji. O obecnej impementacji można przeczytać w zalinkowanym wyżej artykule o nowościach w Javie 14, a o całym koncepcie w dokumencie Pattern Matching for Java. W wydaniu 15 w zasadzie nic się na zewnątrz nie zmieniło, natomiast funkcja ta została oznaczona ponownie jako preview, by zebrać dodatkowe informacje zwrotne.

Garbage Collectory

Byłoby dziwnie, gdyby w kolejnym wydaniu Javy nie działo się nic w dziedzinie odśmiecania. Tak jest też tym razem. Z fazy testów i eksperymentowania wychodzą dwa garbage collectory — ZGC (JEP 337) i Shenandoah (JEP 379).

ZGC został zaprojektowany z myślą o niskich opóźnieniach przy odśmiecaniu. Wprowadzając go w wersji 11 zespół Javy liczył na czas odśmiecania na poziomie poniżej 10ms, a obecnie trwają prace nad tym, by opóźnienia zredukować poniżej 1ms. Od tego czasu wprowadzono sporo usprawnień i wsparcie dla głównych platform (Windows, macOS, Linux na x86_64 i ARM 64).

Shenandoah stawia natomiast na wykonywanie jak największej pracy równolegle, dzięki czemu również notuje krótkie czasy odśmiecania, niezależnie od wielkości sterty. Podobnie jak ZGC, jest on wieloplatformowy.

Inne nowości

Do Javy dodano implementację Edwards-curve Digital Signature Algorithm (JEP 339), w skrócie EdDSA, czyli algorytmu kryptografii opartej na kluczu publicznym i skręconych krzywych Edwardsa. Jest to o tyle ciekawy algorytm podpisu, że, w przeciwieństwie do algorytmu opartego na krzywych eliptycznych (ECDSA), nie wymaga generatora liczb pseudolosowych (co jest o tyle ważne, że dwie sygnatury ECDSA z tą samą wartością losową ujawniają klucz prywatny). Implementacja jest zgodna z RFC 8032.

W inkubatorze wylądowała kolejna iteracja Foreign-Memory Access API (JEP 338), czyli API do bezpiecznego dostępu do pamięci znajdującej się poza stertą Javy.

Nowej implementacji doczekało się DatagramSocket API (JEP 373). API to było obecne w Javie od wersji 1.0 i utrzymanie go przyprawiało zespół Javy o ból głowy. Powstał więc wrapper, który umożliwia wykorzystanie nowej implementacji i pozostawienie starej, dla systemów legacy.

I usuwanie staroci

Z Javy 15 wylatują:

Silnik JavaScriptu Nashorn (JEP 372), który był oznaczony jako przestarzały od czasu Javy 11
Porty dla Solarisa i Linuxa na SPARC (i kod specyficzny dla tych platform), które zostały oznaczone w Javie 14 jako przestarzałe (JEP 381)

A jako przestarzałe zostają oznaczone:

Implementacja Remote Object Activation (JEP 385)
Biased Locking, czyli obecnie mało używany mechanizm synchronizacji (JEP 374). Domyślnie będzie to wyłączony mechanizm.

I to właśnie podsumowanie wszystkich 14 Java Enhancement Proposals, które trafiły do nowej wersji Javy. Zachęcam też do zajrzenia do opisów poprzednich wersji: