gik|iewicz

Ponad 197 000 linii kodu zmieniło Javę na zawsze po 12 latach prac. Project Valhalla, rozpoczęty w 2014 roku, oficjalnie trafia do wydania JDK 28 jako funkcja podglądowa (preview). Architekt języka Brian Goetz ostrzega jednak, że w kolejnym wydaniu LTS status preview prawdopodobnie się utrzyma.

TL;DR: Project Valhalla wprowadza value classes (JEP 401) do JDK 28 po 12 latach rozwoju. Zmiana obejmuje 197 000 linii kodu i ma na celu spłaszczenie pamięci oraz poprawę wydajności. Funkcja trafia jako preview, a pełna stabilizacja potrwa jeszcze przez kilka kolejnych wydań.

Czym jest Project Valhalla w JDK 28?

Project Valhalla to inicjatywa mająca na celu wprowadzenie value types do ekosystemu Java, rozwijana nieprzerwanie od 2014 roku. Głównym celem jest zniwelowanie różnicy wydajnościowej między prymitywami a obiektami, co ma ogromne znaczenie dla obciążeń pamięciowych. W JDK 28 funkcja ta wchodzi w fazę preview jako JEP 401 (value classes). To krok milowy.

Dotychczasowa architektura JVM wymuszała alokację każdego obiektu na stercie, co generowało znaczne koszty pamięciowe oraz narzut na garbage collector. Value classes rozwiązują ten problem, pozwalając na przechowywanie danych bezpośrednio w tablicach lub polach innych obiektów, bez pośrednictwa referencji. Przede wszystkim eliminują to wąskie gardło.

Jak działają value classes według JEP 401?

Value classes pozwalają na tworzenie obiektów, które nie posiadają tożsamości (identity), co odróżnia je od klasycznych klas w Javie. Oznacza to, że dwa obiekty value class z tymi samymi polami są uznawane za równe. W rezultacie JVM może traktować je podobnie do prymitywów, optymalizując układ pamięci i redukując narzut na alokację (JVM Weekly).

Brak tożsamości ma kluczowe implikacje dla modelu pamięci. Klasyczne obiekty wymagają nagłówka oraz referencji, co w przypadku milionów małych instancji drastycznie zwiększa zużycie pamięci. Value classes są pozbawione tego narzutu. Ponadto umożliwiają wektoryzację operacji, co może przynieść znaczne przyspieszenie w obliczeniach numerycznych (The Register).

Oto najważniejsze różnice między klasycznymi klasami a value classes:

• Brak tożsamości – dwie instancje z tymi samymi wartościami pól są traktowane jako identyczne, co upraszcza porównywanie.
• Spłaszczona pamięć – wartości przechowywane są bezpośrednio w tablicach lub polach, bez konieczności stosowania referencji.
• Brak dziedziczenia – value classes nie mogą dziedziczyć po innych obiektach (z wyjątkiem java.lang.Object), co zapobiega złożoności polimorficznej.
• Wąskie ograniczenia synchronizacji – ponieważ nie mają tożsamości, operacje synchronizowane (np. synchronized) na ich instancjach są niedozwolone.
• Wydajność numeryczna – idealne do reprezentacji wektorów, punktów i macierzy, gdzie narzut referencyjny był dotychczas problemem.
• Optymalizacja garbage collectora – krótszy cykl życia obiektów bez tożsamości zmniejsza obciążenie mechanizmów sprzątania pamięci.
• Uproszczony model równości – domyślna implementacja equals opiera się na bitowej równości pól, co eliminuje powtarzalny kod.
• Integracja z BSM (Bootstrap Methods) – nowe instrukcje bytecode’u pozwalają na wydajną inicjalizację wartości na poziomie kompilacji.

Dlaczego JDK 28 to dopiero preview?

Architekt języka Brian Goetz wprost zaznacza, że wprowadzenie value classes to jedna z największych zmian w historii Javy, wymagająca szczególnej ostrożności. Choć kod implementujący JEP 401 obejmuje 197 000 linii, funkcja trafia do JDK 28 jako preview. Mimo to, Goetz ostrzega programistów, że status preview utrzyma się również w kolejnym wydaniu LTS (The Register).

Złożoność wynika z faktu, że value types modyfikują fundamentalne mechanizmy JVM. Konieczne jest sprawdzenie, jak zmiana wpłynie na istniejące biblioteki, narzędzia monitorujące oraz frameworki takie jak Spring czy Hibernate. Na przykład, refleksja i serializacja muszą zostać zaadaptowane do obsługi obiektów bez tożsamości. Tego nie da się przyspieszyć.

Ponadto zespół OpenJDK musi upewnić się, że wydajność value classes w scenariuszach rzeczywistych jest zgodna z założeniami. Optymalizacja JVM pod kątem spłaszczania pamięci wymaga szeroko zakrojonych testów. Wobec tego proces adopcji potrwa znacznie dłużej niż samo wydanie JDK 28 (JVM Weekly).

Kiedy spodziewać się pełnego wydania?

Pełne wdrożenie value classes najprawdopodobniej nastąpi dopiero po wydaniu JDK 29 lub nowszym. Goetz sugeruje, że kolejne LTS (przewidywane na wrzesień 2027 roku) może nadal zawierać JEP 401 w statusie preview. Zatem programiści powinni traktować JDK 28 jako okazję do eksperymentowania, a nie do wdrażania rozwiązań na produkcję. To wymaga cierpliwości.

Harmonogram OpenJDK zakłada iteracyjne zbieranie opinii z społeczności. Value classes muszą zostać zintegrowane z uniwersalnymi typami (universal generics), co jest kolejnym etapem Project Valhalla. Choć implementacja w JDK 28 jest funkcjonalna, brakuje pełnego wsparcia dla typów generycznych specjalizowanych pod value classes. To kolejny powód do ostrożności.

Poniższa tabela przedstawia ewolucję Project Valhalla w kontekście wydań JDK:

Warto również zauważyć, że architektura bezpiecznego pod kątem pamięci rozwiązań kryptograficznych często wymaga podobnego podejścia do optymalizacji, co opisano przy okazji wprowadzania GnuPG – kryptografia post-kwantowa trafia do głównej gałęzi. Podobnie jak w kryptografii, tutaj precyzja operacji bitowych odgrywa istotną rolę.

Często zadawane pytania

Czym jest Project Valhalla w JDK 28?

Project Valhalla to inicjatywa OpenJDK uruchomiona w 2014 roku, która wprowadza value classes (JEP 401) w JDK 28 po zmodyfikowaniu 197 000 linii kodu źródłowego.

Jak działają value classes według JEP 401?

Value classes tworzą obiekty pozbawione tożsamości, co pozwala JVM na spłaszczenie pamięci i traktowanie ich analogicznie do prymitywów, drastycznie zmniejszając narzut na stertę.

Dlaczego JDK 28 to dopiero preview?

Wprowadzenie value classes wymaga zmiany fundamentalnych mechanizmów JVM, dlatego architekt Brian Goetz ostrzega, że status preview utrzyma się również w kolejnym wydaniu LTS.

Kiedy spodziewać się pełnego wydania?

Pełne wdrożenie i stabilizacja value classes najprawdopodobniej nastąpi dopiero po wydaniu JDK 29, z uwagi na konieczność integracji z uniwersalnymi typami (universal generics).