1 10/10/2026 8 min

JDK 21 su Debian 12: la strada pulita è partire dal pacchetto giusto

Su Debian 12 la scelta più lineare per avere Java 21 è usare i repository ufficiali, quando il pacchetto è disponibile, oppure un archivio esterno solo se serve davvero una versione specifica o un ciclo di aggiornamento più rapido. In pratica: prima verifichi cosa offre APT, poi installi, poi controlli che il runtime e il compilatore puntino davvero alla release attesa. Saltare questi passaggi porta spesso a una macchina che “ha Java”, ma non la versione che pensavi di aver messo.

Qui l’obiettivo è semplice: ottenere un JDK 21 funzionante, impostarlo correttamente su Debian 12, verificare che le alternative di sistema siano coerenti e lasciare un percorso di rollback chiaro. Non serve fare acrobazie con script esterni se il pacchetto è già disponibile nel tuo ambiente.

Verifica iniziale: cosa c’è già sul sistema

Prima di installare, conviene capire se esiste già una versione di Java e quale pacchetto propone Debian. Questo evita di sovrascrivere un JDK usato da applicazioni legacy o da tool di build già tarati su una major diversa.

Controlla la situazione attuale con questi comandi:

java -version
javac -version
update-alternatives --query java
update-alternatives --query javac

Se il sistema risponde con un JDK 17, 11 o addirittura con nessun Java installato, sei in una situazione normale. Se invece vedi più percorsi registrati in `update-alternatives`, significa che Debian gestisce già più implementazioni e dovrai scegliere quella corretta dopo l’installazione.

Per sapere se Debian 12 ti offre direttamente il pacchetto, interroga APT:

apt-cache policy openjdk-21-jdk
apt-cache search openjdk-21

Se il pacchetto compare nei repository configurati, puoi restare su un flusso pulito e completamente tracciabile. Se non compare, il problema non è tecnico ma di sorgente software: repository non aggiornati, mirror incompleto o necessità di un canale diverso.

Installazione con APT: preferenza assoluta se il pacchetto è disponibile

Quando `openjdk-21-jdk` è presente, l’installazione è banale e la manutenzione futura resta allineata al resto del sistema. È la scelta migliore per server, container di build e macchine amministrate con criteri standard.

sudo apt update
sudo apt install openjdk-21-jdk

Il pacchetto `openjdk-21-jdk` include sia il runtime sia gli strumenti di compilazione. Se ti serve solo l’esecuzione e non devi compilare codice, puoi valutare `openjdk-21-jre`, ma in ambiente sysadmin di solito il JDK completo è più pratico perché evita di scoprire troppo tardi che manca `javac`.

Dopo l’installazione, verifica subito la versione effettiva:

java -version
javac -version

Il risultato atteso è qualcosa del tipo `21.x`. Non fissarti sul numero di build preciso, che può cambiare con gli aggiornamenti di sicurezza: il punto è vedere la major 21 e un provider OpenJDK coerente.

Se Debian non propone JDK 21: repository esterni, ma con criterio

Se `apt-cache policy openjdk-21-jdk` non mostra candidate installabili, non forzare pacchetti presi a caso. In quel caso hai due strade sane: aggiornare i repository in uso se il mirror è incompleto, oppure adottare una sorgente esterna affidabile e mantenibile. La seconda opzione va scelta solo se hai una ragione concreta, per esempio dipendenze applicative che richiedono Java 21 subito e non puoi aspettare il ciclo del repository Debian che stai usando.

Una pratica comune è usare Adoptium o un altro vendor riconosciuto, ma la procedura cambia in base al canale scelto. Il punto operativo è sempre lo stesso: aggiungi la sorgente, aggiorni gli indici e installi il pacchetto, poi controlli che il binario arrivi dal percorso giusto.

Esempio di verifica post-installazione quando il pacchetto arriva da un repository esterno:

which java
readlink -f /usr/bin/java
java -XshowSettings:properties -version 2>&1 | grep 'java.home'

Se `java.home` punta a una directory coerente con il JDK 21 appena installato, la catena è corretta. Se invece vedi ancora una versione precedente, il problema è nelle alternative o nella priorità del pacchetto installato.

Gestire più Java sullo stesso host senza confondersi

Su server reali non esiste quasi mai una sola Java. Puoi avere JDK diversi per applicazioni diverse, agent di monitoraggio, tool di build e qualche servizio vecchio che non vuole morire. Per questo Debian usa `update-alternatives`, che ti permette di scegliere il binario predefinito senza toccare a mano i symlink sparsi nel filesystem.

Per vedere le alternative disponibili:

sudo update-alternatives --config java
sudo update-alternatives --config javac

Seleziona il percorso che punta al JDK 21. Dopo la scelta, ricontrolla:

java -version
javac -version

Questo passaggio sembra banale, ma evita un errore frequente: installare la versione giusta e continuare a usare quella sbagliata perché il sistema conserva una priorità più alta per un runtime precedente.

Se vuoi verificare anche il percorso delle alternative in modo non ambiguo:

ls -l /etc/alternatives/java
ls -l /etc/alternatives/javac

Il target deve puntare dentro una directory del JDK 21, ad esempio sotto `/usr/lib/jvm/`. Se non è così, stai guardando un problema di configurazione, non di installazione.

Variabili d’ambiente: quando servono davvero

Per molti servizi systemd non serve esportare nulla a livello globale: basta che il servizio punti al binario corretto o che il wrapper dell’applicazione conosca il `JAVA_HOME`. Le variabili d’ambiente diventano utili soprattutto su host di sviluppo, pipeline CI o macchine dove convivono più runtime e vuoi rendere il comportamento esplicito.

Trova il percorso del JDK installato e imposta `JAVA_HOME` in modo persistente. Su Debian, il percorso tipico è qualcosa come `/usr/lib/jvm/java-21-openjdk-amd64`, ma verifica sempre il nome reale sul tuo sistema:

readlink -f $(which javac)
dpkg -L openjdk-21-jdk | grep '/bin/javac$'

Per un singolo utente, puoi esportare la variabile nel file `~/.bashrc` o `~/.profile`:

export JAVA_HOME=/usr/lib/jvm/java-21-openjdk-amd64
export PATH=$JAVA_HOME/bin:$PATH

Dopo la modifica, ricarica la shell e controlla:

echo $JAVA_HOME
java -version
javac -version

Per servizi systemd è meglio non dipendere dalla shell interattiva. In quel caso, usa un drop-in o definisci l’ambiente nel file unit, ad esempio con `Environment=JAVA_HOME=...`. È più pulito e riduce i casi in cui il servizio parte nel terminale ma fallisce al boot.

Verifiche funzionali: non basta che il comando risponda

Un `java -version` corretto dice solo che il binario risponde. Non ti dice se il compilatore funziona, se le alternative sono coerenti o se il runtime riesce a caricare le librerie native attese. Per questo conviene fare almeno una verifica funzionale minima.

cat > /tmp/TestJava.java <<'EOF'
public class TestJava { public static void main(String[] args) { System.out.println(System.getProperty("java.version")); }
}
EOF
javac /tmp/TestJava.java
java -cp /tmp TestJava

Il risultato atteso è la stampa della versione 21.x. Se la compilazione fallisce, hai un problema nel JDK o nelle alternative. Se la compilazione riesce ma l’esecuzione no, controlla il path, le variabili d’ambiente e l’eventuale presenza di wrapper o alias personalizzati.

Su host usati per build automation, vale la pena verificare anche Maven o Gradle se presenti. Non perché Java 21 non funzioni, ma perché alcuni progetti ereditati hanno plugin o configurazioni che bloccano la major e richiedono un aggiornamento del toolchain, non del solo runtime.

Integrazione con applicazioni e servizi systemd

Se Java 21 serve a un servizio specifico, non affidarti al fatto che il sistema abbia un default globale corretto. È meglio dichiarare il runtime in modo esplicito nel servizio o nello script di avvio, così il comportamento resta stabile anche quando un amministratore cambia le alternative a livello host.

Esempio di unit file con ambiente esplicito:

[Service]
Environment="JAVA_HOME=/usr/lib/jvm/java-21-openjdk-amd64"
ExecStart=/usr/lib/jvm/java-21-openjdk-amd64/bin/java -jar /opt/app/app.jar

Se modifichi una unit esistente, usa un drop-in invece di riscrivere tutto il file. È un approccio meno fragile e più facile da versionare:

sudo systemctl edit nome-servizio

Dopo la modifica:

sudo systemctl daemon-reload
sudo systemctl restart nome-servizio
sudo systemctl status nome-servizio --no-pager

Qui il controllo non è solo “parte”, ma anche “parte con la versione giusta”. Se l’applicazione espone un endpoint di health o un log di bootstrap, usalo per confermare che sta girando su Java 21 e non su un runtime residuo.

Rollback e rimozione pulita

Se qualcosa non torna, il rollback deve essere semplice. L’obiettivo non è cancellare tutto, ma tornare a uno stato noto e funzionante. Se hai cambiato solo le alternative, puoi ripristinare la precedente versione con `update-alternatives --config`. Se hai aggiunto un repository esterno, rimuovi prima quella sorgente e poi disinstalla il pacchetto che dipende da quel canale, solo se non serve ad altre applicazioni.

Verifica i pacchetti installati prima di togliere qualcosa:

dpkg -l | grep -E 'openjdk|java|jdk|jre'
apt-cache policy openjdk-21-jdk

Se devi rimuovere il JDK 21 installato da APT:

sudo apt remove openjdk-21-jdk
sudo apt autoremove

Non eseguire `autoremove` alla cieca se sulla macchina hai altri pacchetti Java collegati a tool di build o agent di terze parti. Prima controlla l’elenco dei pacchetti da rimuovere che APT propone a video. Il blast radius qui è medio: puoi impattare build, servizi e script che assumono la presenza di `java` o `javac` nel PATH.

Assunzione operativa: Debian 12 con privilegi sudo disponibili e nessun requisito particolare di vendor Java imposto da applicazioni già in produzione.

Checklist finale da tenere vicino alla tastiera

Un’installazione fatta bene su Debian 12 si chiude con cinque controlli concreti: il pacchetto è quello atteso, `java` e `javac` mostrano la major 21, `update-alternatives` punta al percorso corretto, `JAVA_HOME` è coerente se lo usi, e il servizio o la shell che deve usare Java vede davvero quel runtime.

Se uno di questi punti manca, non considerare l’installazione conclusa. Su sistemi Linux la differenza tra “installato” e “utilizzabile” è quasi sempre nel dettaglio del path, non nel comando di `apt install`.