> ## Content Index
> Fetch the complete content index at: https://lsdev.pl/llms.txt
> Use this file to discover other available public pages before exploring further.

# Java 21 do 25: kiedy migracja to rzeczywisty problem
- URL: https://lsdev.pl/posts/java-21-do-25-kiedy-migracja-to-rzeczywisty-problem/
- Published: 2026-09-06T19:02:53.000Z
- Updated: 2026-09-06T19:02:53.000Z
- Description: Upgrade na Javę 25 to dwa różne pytania: kalendarz licencji Oracle i rzeczywiste zachowanie wirtualnych wątków. Przeczytaj, na jakiej podstawie podejmować decyzję.
- Author: Łukasz Sakowicz
- Tags: Java, JVM, virtual threads, wirtualne wątki, migracja, #lsdev-ai

Masz klaster produkcyjny na Javie 21 i ktoś przy code review rzuca: „a nie powinniśmy przeskoczyć na 25?”. Zanim otworzysz release notes, zapytaj się, o co tak naprawdę pytasz — o kalendarz licencji Oracle, czy o realny problem w Twoim kodzie z wirtualnymi wątkami. To dwa różne pytania i tylko jedno z nich ma twardą techniczną odpowiedź.

## Harmonogram wsparcia: kiedy naprawdę kończy się darmowa Java 21

Java 21 wyszła we wrześniu 2023 roku jako wydanie LTS. Ale „LTS” w wykonaniu Oracle ma dwa tory. Jeśli używasz Oracle JDK na darmowej licencji NFTC, aktualizacje wydane po wrześniu 2026 roku mają zostać objęte licencją Java SE OTN — tą samą, na jakiej dziś dostajesz aktualizacje do Javy 8, 11 i 17, jak podaje dokumentacja Oracle. Innymi słowy: od października 2026 kończy się darmowe patchowanie produkcji bez umowy komercyjnej.

Wydanie Javy 25 LTS we wrześniu 2025 roku otworzyło roczny okres nakładania się, w którym Oracle chce, żebyś zdążył przenieść się z NFTC-owej 21 na 25, zanim ten model licencji wygaśnie — mówi o tym ta sama dokumentacja Oracle. Jeśli zamiast tego płacisz za Java SE Universal Subscription, presja czasu wygląda inaczej: komercyjne wsparcie dla Javy 21 ma być dostępne co najmniej do września 2031 roku, zgodnie z Oracle Java SE Support Roadmap opisanym na blogu Oracle Java. To jest pierwsza rozstrzygająca decyzja: sprawdź, na jakiej licencji faktycznie stoisz, zanim zaczniesz liczyć JEP-y.

| Licencja                       | Termin graniczny                                | Co robić                                              |
| ------------------------------ | ----------------------------------------------- | ----------------------------------------------------- |
| Oracle JDK 21 NFTC (darmowa)   | aktualizacje po wrześniu 2026 przechodzą na OTN | zaplanuj migrację na 25 przed CPU z października 2026 |
| Java SE Universal Subscription | wsparcie do co najmniej września 2031           | migracja z powodów licencyjnych nie jest pilna        |

## JEP 491: koniec pinning w synchronized

Wirtualne wątki zostały pierwotnie zaproponowane jako funkcja preview w JEP 425 i dostarczone już w JDK 19, a status finalny dostały w Javie 21 jako JEP 444\. Przez trzy kolejne wersje — 21, 22, 23 — miały jedną poważną wadę: wątek wirtualny, który wchodził w blok synchronized, nie mógł odłączyć się od wątku nośnego nawet wtedy, gdy zaraz potem blokował się na operacji I/O, jak opisuje analiza InfoQ. Specyfikacja JEP 491 nazywa problem wprost: częste i długotrwałe przypinanie szkodzi skalowalności.

Według tej samej analizy InfoQ, to właśnie wyczerpanie wątków nośnych przez zablokowane bloki synchronized było dominującą przyczyną awarii w środowiskach na Javie 21 — to jednak ocena redakcyjna InfoQ, nie liczba z benchmarku, więc traktuj ją jako prawdopodobną, nie policzoną. Od Javy 24 monitor obiektu jest, według opisu na blogu programisty Shubhama Raizady, powiązany z samym wątkiem wirtualnym, a nie z wątkiem nośnym — dzięki temu JVM może odmontować wirtualny wątek blokujący się w sekcji synchronized na I/O czy Thread.sleep(). To opis z bloga, nie specyfikacja.

Java 25 jest pierwszym wydaniem LTS, które niesie tę poprawkę razem ze sfinalizowanymi scoped values, jak stwierdza InfoQ — i to jest jedyny argument w tym zestawieniu, który nie jest kwestią kalendarza, tylko realnym zachowaniem JVM pod obciążeniem. Jeśli Twój kod trzyma synchronized na ścieżkach obsługiwanych przez wirtualne wątki — połączenia do bazy, blokady na współdzielonych zasobach — to jest powód, żeby migrować, zanim zrobi to za Ciebie kalendarz licencji. Przed Javą 24 zgłoszono pojedynczy przypadek zakleszczenia inicjalizacji HikariCP i Logback pod wirtualnymi wątkami, opisany w InfoQ jako Issue #2293 — jeden raport, nie wzorzec, ale pokazuje, jak nieoczywiste bywają skutki pinningu.

## Co jeszcze przynosi 25 — i czego nie musisz ruszać

Scoped values (JEP 487) to, według specyfikacji OpenJDK, wartość zapisywana raz i dostępna tylko przez ograniczony czas działania wątku — w przeciwieństwie do ThreadLocal, którą można nadpisywać dowolnie. Wątki potomne uruchamiane przez StructuredTaskScope dziedziczą te wartości automatycznie, bez kopiowania powiązań jak przy ThreadLocal. To wygodny model dla nowego kodu współbieżnego, ale nie jest powodem migracji istniejącej aplikacji — to zmiana sposobu programowania, nie poprawka błędu.

Sam StructuredTaskScope w Javie 25 wciąż jest piątym preview (JEP 505) — nie ma już publicznych konstruktorów, a domyślna fabryka open() tworzy zakres, który przy pierwszym rzuconym wyjątku przerywa pozostałe podzadania, jak opisuje InfoQ. Status preview oznacza jedno: nie opieraj na tym API kodu produkcyjnego, dopóki się nie ustabilizuje.

Generacyjny ZGC, który bywa wymieniany jako argument za nowszą Javą, w rzeczywistości stał się domyślnym trybem jeszcze przed 25, a tryb niegeneracyjny usunięto już w Javie 24 — to nie jest powód, żeby czekać akurat na wydanie 25\. Podobnie podglądowe funkcje, jak dopasowanie wzorców dla typów prymitywnych (JEP 507) czy dokładniejsze profilowanie czasu CPU w JFR (JEP 509), opisane w release notes Oracle, są ciekawe do testów, ale nie zmieniają rachunku decyzyjnego dla usługi na produkcji.

## Migrować teraz, czekać, czy pominąć 21?

Jeśli zaczynasz nowy projekt, nie ma dylematu — idź prosto w 25, bo to pierwsze LTS z poprawką pinningu i sfinalizowanymi scoped values. Jeśli masz już produkcję na 21 i intensywnie używasz synchronized na ścieżkach z wirtualnymi wątkami, migracja jest uzasadniona teraz, niezależnie od licencji — poprawka dotyczy zachowania JVM, nie publicznego API — testy regresyjne pod realnym obciążeniem są konieczne. Jeśli wirtualnych wątków nie używasz wcale albo używasz ich bez synchronized na gorących ścieżkach, jedynym realnym driverem jest kalendarz: sprawdź licencję i zaplanuj przejście przed październikowym CPU 2026, chyba że masz Universal Subscription — wtedy masz czas do 2031 i możesz migrować przy okazji kolejnego cyklu, bez pośpiechu.