Którą wersję Javy wybrać? Przegląd dla serwerów

Java rzadko trafia na serwer sama dla siebie. Jest tam dlatego, że wymaga jej serwer Minecraft, Tomcat, Jenkins albo indeks wyszukiwania. Właśnie dlatego pytanie nigdy nie brzmi „która Java jest najlepsza”, tylko „której Javy oczekuje ta konkretna aplikacja i czy w ogóle dostanę ją na tym konkretnym systemie operacyjnym”. Ten artykuł odpowiada na jedno i drugie: harmonogramami wsparcia, tabelą dostępności, którą sprawdziliśmy w prawdziwych kontenerach, oraz praktyką równoległej pracy kilku wersji.

W skrócie: która wersja do czego

Jeśli nie masz czasu, decyzja wygląda tak:

• Nowy projekt, wolny wybór: Java 21. To obecnie najszerzej wspierana linia LTS, dostępna jako gotowy pakiet w Debianie 13 i we wszystkich aktualnych wersjach Ubuntu, a praktycznie każde aktualne oprogramowanie serwerowe na niej działa.
• Minecraft od 1.20.5 do 1.21.11: Java 21. Obowiązkowo, bez pola manewru.
• Minecraft 26.1 i nowszy: Java 25.
• Starsza aplikacja, która ma w dokumentacji „Java 17”: weź Javę 17, a nie „17 lub nowszą”. Przy modloaderach i systemach wtyczek „nowsza” często nie jest prawdą.
• Java 8 albo 11: już tylko wtedy, gdy wymusza to stara aplikacja. Obie trafiają na twoją listę rzeczy do wymiany.
• Java 25: najnowsza linia LTS, sensowna przy nowych wdrożeniach, ale sprawdź wcześniej, czy twój framework ma już oficjalne dopuszczenie.

Na samą instalację mamy osobne poradniki: Instalacja Javy 17 na Debianie oraz Instalacja Javy 21 na Debianie. Ten artykuł to mapa, która je porządkuje.

Co oznacza LTS i jak długo wersje są wspierane

Nowe wydanie główne Javy ukazuje się co pół roku. Zdecydowana większość z nich jest martwa dokładnie po tych sześciu miesiącach: Java 22, 23, 24 i 26 nie dostają już żadnej aktualizacji bezpieczeństwa, gdy tylko pojawi się kolejna wersja. Na serwerze nie chcesz ich mieć.

Interesujące są wyłącznie wersje LTS (Long Term Support). Od 2021 roku wychodzą co dwa lata: 8, 11, 17, 21, 25, a jako następna zaplanowana jest Java 29 na wrzesień 2027. Tylko te linie dostają przez lata kwartalne aktualizacje bezpieczeństwa.

Ważne jest rozróżnienie między Oracle a darmowymi kompilacjami. Do pracy serwerowej sięgasz z reguły po OpenJDK z pakietu dystrybucyjnego albo po Eclipse Temurin. Obie drogi są bezpłatne, a wsparcie trwa tam miejscami znacznie dłużej niż przy darmowej licencji Oracle.

Wiersz dla Javy 17 wielu zaskakuje: już tylko do października 2027. Java 17 sprawia wrażenie nowej, a jest już przedostatnią generacją LTS. Jeśli stawiasz dziś system, który ma działać przez trzy lata, lepiej od razu zaplanuj 21 albo 25.

Którą wersję Javy twoja dystrybucja ma we własnym repozytorium

Tu wykłada się większość poradników w sieci: piszą „apt install openjdk-17-jre-headless” i zakładają, że zadziała wszędzie. Nie zadziała. Stan pakietów sprawdziliśmy 27 lipca 2026 w świeżych kontenerach.

Przeczytaj kolumny Debiana dwa razy. Debian 12 zna wyłącznie Javę 17. Debian 13 nie zna już Javy 17, za to ma 21 i 25. W oficjalnych źródłach Debiana nie ma więc ani jednej wersji obecnej w obu wydaniach. Jeśli piszesz skrypt wdrożeniowy, który ma działać na bookworm i trixie, nie możesz oprzeć się na jednym pakiecie.

Ubuntu jest pod tym względem przyjemniejsze: wszystkie pięć linii LTS leży tam obok siebie w repozytorium, na 22.04 tak samo jak na 24.04. Jeśli potrzebujesz systemu, na którym równocześnie działa stara aplikacja na Javie 8 i nowoczesna usługa na Javie 21, Ubuntu jest drogą na skróty.

W razie wątpliwości sprawdź sam, zamiast zgadywać:

apt update
apt-cache policy openjdk-21-jre-headless
apt-cache search openjdk-

Jeśli przy „Kandydująca”, po angielsku „Candidate”, widnieje (brak), tego pakietu w tej dystrybucji nie ma. W rodzinie Red Hat (AlmaLinux, Rocky, RHEL, Oracle Linux) pakiety nazywają się inaczej, tam listujesz je tak:

dnf list java-\*-openjdk-headless
dnf install -y java-21-openjdk-headless

Do przeglądu użyj dnf list, a nie dnf list available. To drugie ukrywa pakiety już zainstalowane, więc po instalacji Javy 21 sama Java 21 znika z listy i szukasz w złym miejscu. Sytuacja w rodzinie Red Hat, również zmierzona w świeżych kontenerach:

AlmaLinux 10 zrobił więc dokładnie takie samo cięcie jak Debian 13 i porzucił wszystko poniżej 21. Polecenie dnf install java-17-openjdk-headless kończy się tam komunikatem No match for argument.

headless czy nie, JRE czy JDK

Na serwerze zawsze bierz wariant -headless. Rezygnuje on z bibliotek graficznych i nie ciągnie za sobą zależności X11, co na serwerze root oszczędza dziesiątki zbędnych pakietów. A -jre-headless wystarczy, dopóki tylko uruchamiasz gotowe pliki JAR. Dopiero gdy sam kompilujesz albo jakieś narzędzie wywołuje javac, potrzebujesz openjdk-21-jdk-headless.

W rodzinie Red Hat warto w tym miejscu rzucić drugie spojrzenie na zależności. Pakiet java-21-openjdk-devel ciągnie na AlmaLinux 9 zaskakująco długi łańcuch pakietów graficznych, w tym webkit2gtk3-jsc, xorg-x11-fonts, xdg-desktop-portal i wireplumber. Na serwerze bez interfejsu graficznego nikt tego nie chce. Sprawdź więc wcześniej poleceniem dnf install --assumeno, co faktycznie przyjdzie razem z pakietem, i zostań przy java-21-openjdk-headless, dopóki nie musisz nic kompilować.

Minecraft: wersja gry a wersja Javy

Minecraft jest najczęstszym powodem, dla którego ktokolwiek w ogóle wgrywa Javę na serwer, a zarazem obszarem o najostrzejszych wymaganiach. Przyporządkowanie jest jednoznaczne:

Dwie rzeczy, których w większości tabel brakuje. Po pierwsze: wraz z 26.1 Minecraft porzucił stary schemat 1.x i przeszedł na numerację rocznikową, 26.1 to więc pierwsze wydanie roku 2026. Wersja 1.21.11 była ostatnią, której wystarcza Java 21.

Po drugie: „lub nowsza” obowiązuje dla serwera vanilla. Gdy w grę wchodzą modloadery, przestaje to być pewne. Serwer Forge dla 1.20.1 jest zbudowany na Javie 17, a przestawienie go na Javę 21 należy do najczęstszych przyczyn wysypywania się serwera zaraz po starcie, choć liczba jest przecież „większa”. Przy serwerach z modami bierz dokładnie tę wersję, którą podaje autor modpacka.

Praktyczne wykonanie opisują nasze poradniki Instalacja serwera Minecraft na Debianie oraz Automatyczny start serwera Minecraft.

Inne aplikacje serwerowe i ich wymagania

Poza Minecraftem obowiązują z grubsza te reguły:

• Apache Tomcat: 9.0.x działa od Javy 8, 10.1.x wymaga co najmniej Javy 11, 11.0.x co najmniej Javy 17. Wszystkie trzy aktualnie wspierane gałęzie działają na Javie 17 bez zarzutu.
• Elasticsearch i OpenSearch: przynoszą własną maszynę JVM. Nie instaluj tam systemowej Javy i nie ustawiaj globalnego JAVA_HOME, które nadpisze dołączoną JVM. To klasyczne źródło błędów po „porządkach” w instalacji Javy.
• Jenkins: aktualne wersje wymagają co najmniej Javy 17 i działają na Javie 21.
• Keycloak, Kafka, Solr, Nexus: trzymają się każdorazowo przedostatniego LTS. Sprawdź informacje o wydaniu konkretnej wersji, te projekty regularnie podnoszą dolną granicę.

Nie każde oprogramowanie serwerowe, które kojarzy się z Javą, faktycznie jej potrzebuje. Serwer TeamSpeak 3 jest na przykład natywnym plikiem binarnym i obywa się bez JVM.

Kilka wersji Javy równolegle i przełączanie między nimi

Na Debianie i Ubuntu możesz zainstalować równocześnie dowolnie wiele pakietów OpenJDK. Każdy ląduje we własnym katalogu w /usr/lib/jvm/ i nie przeszkadzają sobie nawzajem:

apt install -y openjdk-21-jre-headless openjdk-25-jre-headless
ls /usr/lib/jvm/

Współdzielą dokładnie jeden plik: /usr/bin/java. To dowiązanie symboliczne, którym zarządza mechanizm alternatives. Kandydatów wyświetlisz tak:

update-alternatives --list java
update-alternatives --display java

Ten zapis z nazwą po --list jest specyficzny dla Debiana, w rodzinie Red Hat wygląda inaczej, o czym więcej poniżej. Ważniejsze z tych dwóch jest wyjście --display. Pokazuje nie tylko ścieżki, ale też tryb (auto albo manual) i priorytet każdego wpisu. Przełączać można interaktywnie poleceniem update-alternatives --config java i wyborem numeru, a w skryptach lepiej na sztywno:

update-alternatives --set java /usr/lib/jvm/java-21-openjdk-amd64/bin/java
java -version

Ścieżki nigdy przy tym nie przepisuj z cudzego poradnika, tylko weź ją z update-alternatives --list java. Pokazana wyżej ścieżka dotyczy OpenJDK z pakietu dystrybucyjnego. Kto pójdzie za opisanym niżej rozdziałem o Temurinie, ten takiego katalogu w ogóle nie ma, tam nazywa się on /usr/lib/jvm/temurin-21-jre-amd64/bin/java, a polecenie przerywa z komunikatem alternative path ... doesn't exist.

Jeśli także kompilujesz, javac trzeba przestawić osobno. O tym chętnie się zapomina, co prowadzi do absurdalnej sytuacji, w której kompilacja idzie Javą 25, a start Javą 21:

update-alternatives --set javac /usr/lib/jvm/java-21-openjdk-amd64/bin/javac
javac -version

Pułapka, która kosztuje cię nieprzespaną noc

Dopóki java stoi w trybie auto, zawsze wygrywa najwyższy priorytet, a najwyższy priorytet ma najnowsza zainstalowana wersja. Jeśli więc miesiące później dołożysz openjdk-25, bo potrzebuje go inna usługa, /usr/bin/java przy najbliższej operacji na pakietach po cichu przeskoczy na 25. Twój serwer Minecraft, który do tej pory chodził na 21, po następnym restarcie wystartuje na maszynie JVM, której nigdy nie wybrałeś.

update-alternatives --set przełącza wpis na manual i tym samym go zamraża. To właściwy cel tego polecenia. Do trybu automatycznego wrócisz tak:

update-alternatives --auto java

Mimo to solidniejszą drogą dla usług jest w ogóle nie polegać na /usr/bin/java. Wpisz w swojej jednostce systemd pełną ścieżkę, wtedy wybór wersji jest zapisany na stałe dla danej usługi i niezależny od każdej zmiany w mechanizmie alternatives:

ExecStart=/usr/lib/jvm/java-21-openjdk-amd64/bin/java -Xms2G -Xmx4G -jar server.jar nogui

Jak taka jednostka wygląda w całości, opisuje wpis Tworzenie usługi systemd. Dokładnie ta bezwzględna ścieżka jest zresztą też powodem, dla którego usługa po zmianie Javy czasem nie przechodzi na nową wersję: update-alternatives po prostu jej nie rusza.

Na systemach AlmaLinux, Rocky Linux, RHEL i Oracle Linux narzędzie nazywa się alternatives, a update-alternatives jest tam tylko dowiązaniem do niego. Działa jednak inaczej: tamto --list nie przyjmuje argumentu. Skopiowane update-alternatives --list java wypisuje tam tylko tekst pomocy i kończy się kodem powrotu 2. Poprawny jest jeden z tych dwóch wierszy:

alternatives --list | grep java
alternatives --display java

Odbiega też wyjście --display: zamiast java - auto mode stoi tam java - status is auto. Ścieżki zawierają w rodzinie Red Hat dodatkowo pełny numer wersji, czyli na przykład /usr/lib/jvm/java-21-openjdk-21.0.11.0.10-1.el9.x86_64, a nie krótką formę Debiana java-21-openjdk-amd64. Tylko AlmaLinux 10 zakłada dodatkowo krótkie dowiązanie java-21-openjdk.

Automatyka zachowuje się tam też inaczej, niż można by oczekiwać: po instalacji Javy 17 obok obecnej już Javy 21 alternatives na AlmaLinux 9 samoczynnie przestawił dowiązanie /usr/bin/java na 17, czyli na starszą wersję. Po każdej dodatkowej instalacji ustaw więc wyraźnie alternatives --set java <ścieżka> i sprawdź wynik poleceniem java -version.

Gdy dystrybucja nie ma danej wersji: Temurin

Na luki w powyższej tabeli jest czyste rozwiązanie: Eclipse Temurin od Adoptium dostarcza temurin-8 do temurin-26 dla trixie, bookworm, noble i jammy. Dzięki temu dostaniesz Javę 21 także na Debianie 12 i Javę 17 także na Debianie 13, bez obcych repozytoriów PPA i bez ręcznie kopiowanych archiwów w /opt.

Pamiętaj przy tym, że apt-key jest wycofany. Klucz trafia do /etc/apt/keyrings/ i wskazuje się na niego przez signed-by:

apt install -y wget gnupg ca-certificates apt-transport-https
install -d -m 0755 /etc/apt/keyrings
wget -qO - https://packages.adoptium.net/artifactory/api/gpg/key/public | gpg --dearmor | tee /etc/apt/keyrings/adoptium.gpg > /dev/null
echo "deb [signed-by=/etc/apt/keyrings/adoptium.gpg] https://packages.adoptium.net/artifactory/deb $(awk -F= '/^VERSION_CODENAME/{print$2}' /etc/os-release) main" | tee /etc/apt/sources.list.d/adoptium.list
apt update
apt install -y temurin-21-jre

Pakiety Temurin rejestrują się również w mechanizmie alternatives, pojawiają się więc w update-alternatives --display java i można je mieszać z pakietami OpenJDK z dystrybucji. Ich katalogi leżą w /usr/lib/jvm/temurin-21-jre-amd64 albo pod podobnie zbudowaną nazwą.

Komunikaty błędów dosłownie i co oznaczają

E: Unable to locate package openjdk-17-jre-headless
Ta wersja w tej dystrybucji nie istnieje. Na Debianie 13 to normalny przypadek dla Javy 8, 11 i 17. Żadna literówka, żadne brakujące apt update: weź Temurin albo inną wersję.

java.lang.UnsupportedClassVersionError: ... has been compiled by a more recent version of the Java Runtime (class file version 65.0), this version of the Java Runtime only recognizes class file versions up to 61.0
Klasyk. Aplikacja została zbudowana pod nowszą maszynę JVM niż ta, którą uruchomiłeś. Liczby przekładają się tak:

65.0 przeciw 61.0 oznacza więc wprost: oprogramowanie chce Javy 21, a u ciebie działa Java 17. Przy serwerach Minecraft od 1.20.5 widzisz ten błąd często opakowany jako Error: LinkageError occurred while loading main class net.minecraft.bundler.Main, właściwa przyczyna stoi wtedy w wierszu poniżej.

java: command not found
Nie ma zainstalowanej żadnej maszyny JVM albo rozpakowałeś tylko katalog JDK do /opt, nie rejestrując go. Sprawdź ls /usr/lib/jvm/. Jeśli są tam katalogi, a /usr/bin/java brakuje, zarejestruj wpis ręcznie:

update-alternatives --install /usr/bin/java java /usr/lib/jvm/java-21-openjdk-amd64/bin/java 2111

update-alternatives: error: no alternatives for java
Mechanizm alternatives nie zna w ogóle żadnego kandydata. Zdarza się, gdy Java została zainstalowana ręcznie. Ta sama poprawka co wyżej.

update-alternatives: error: alternative path /usr/lib/jvm/... doesn't exist
Ustawiłeś ścieżkę, której już nie ma, zwykle po deinstalacji. Zwróć uwagę, że ścieżki Debiana zawierają architekturę: java-21-openjdk-amd64, a nie java-21-openjdk.

Usługa działa, ale na złej wersji.
Bardzo prawdopodobnie w jednostce systemd stoi bezwzględna ścieżka albo jednostka ustawia własne JAVA_HOME. Jedno i drugie przebija update-alternatives bez żadnego ostrzeżenia.

Serwer startuje, ale po kilku sekundach ginie bez zrozumiałego komunikatu.
Przy aplikacjach Javy to często nie problem wersji, tylko brak pamięci: kernel kończy proces, gdy -Xmx jest ustawione wyżej niż wolna pamięć RAM. Pasują do tego nasze artykuły Konfiguracja swapa przeciw Out of Memory oraz Pełny dysk w Linuksie: jak zwolnić miejsce.

Po czym poznasz, że naprawdę działa właściwa wersja

Pierwsze sprawdzenie jest banalne, ale mimo to rób je po każdej zmianie:

java -version

Wynik musi podać oczekiwane wydanie główne, na przykład openjdk version "21.0.11". Drugie sprawdzenie mówi więcej, bo pokazuje faktycznie rozwiązaną ścieżkę, a tym samym także to, czy trafiłeś na Temurin, czy na OpenJDK z dystrybucji:

readlink -f "$(command -v java)"

Użyj tu świadomie command -v, a nie which. which to zewnętrzny program, a w minimalnej instalacji AlmaLinux 9 i 10, Rocky Linux 9 oraz Oracle Linux 9 w ogóle go nie ma. Wariant z which kończy się tam komunikatem which: command not found, a zaraz po nim readlink: missing operand. command -v jest wbudowane w powłokę i działa na wszystkich wymienionych dystrybucjach.

A jeśli chcesz wiedzieć, co sama JVM sądzi o swoim miejscu w systemie, bo jakaś aplikacja odczytuje JAVA_HOME:

java -XshowSettings:properties -version

W wyniku interesują cię java.home i java.version. Jeśli java.home odbiega od twoich oczekiwań, gdzieś ustawione jest JAVA_HOME, które wygrywa.

Przy działającej usłudze liczy się na końcu tylko to, czego używa sam proces. Odczytasz to wprost z listy procesów, stoi tam pełna ścieżka maszyny JVM, z którą usługa wystartowała:

ps -eo pid,args | grep '[j]ava'

Jeśli widzisz tam /usr/lib/jvm/java-21-openjdk-amd64/bin/java, sprawa jest załatwiona. Jeśli widzisz gołe java, twoja usługa wisi na dowiązaniu z mechanizmu alternatives i zmienia się razem z nim. Dla usługi produkcyjnej to gorszy z obu wariantów.

Jeśli i tak właśnie stawiasz serwer od zera, warto wcześniej zajrzeć do naszej listy kontrolnej dla nowych serwerów root: miejsce Javy jest na końcu tej listy, a nie na jej początku, bo dopiero przy działającym dostępie SSH, firewallu i ustawionej strefie czasowej szukanie błędów w JVM ma jakikolwiek sens.

Podsumowanie

Java 21 jest dziś odpowiedzią domyślną, Java 25 odpowiedzią na przyszłość, Java 17 wersją wygasającą, a Java 8 i 11 to dług migracyjny. Decyduje jednak nie sama liczba, tylko połączenie aplikacji z dystrybucją: Debian 12 da ci tylko 17, Debian 13 tylko 21 i 25, Ubuntu da ci wszystko. Tam, gdzie pakietu brakuje, lukę wypełnia Temurin. A gdy tylko na maszynie leży więcej niż jedna wersja, obowiązuje zasada: update-alternatives --set zamiast automatyki, a w jednostkach systemd lepiej od razu bezwzględna ścieżka.