DynamoDB Locale: UnsupportedClassVersionError

TL;DR: il tuo runtime Java è precedente a quello per cui è stato compilato DynamoDB Local. L'attuale DynamoDB Locale (v2.6.0 e successive, inclusa v3.x) richiede JRE 17+: avviandolo su Java 8/11, la JVM rifiuta i file di classe con UnsupportedClassVersionError. Installa un runtime Java 17+ (Temurin, Corretto, ...) ed eseguilo nuovamente oppure salta completamente Java locale con l'immagine Docker amazon/dynamodb-local.

Cosa significa

Error: A JNI error has occurred...
java.lang.UnsupportedClassVersionError: com/amazonaws/services/dynamodbv2/local/main/ServerRunner
has been compiled by a more recent version of the Java Runtime
(class file version 61.0), this version of the Java Runtime only
recognizes class file versions up to 52.0

Questo è un Errore della JVM, non un'Eccezione del servizio DynamoDB: il processo termina prima di DynamoDB Locale vincola una porta. La versione del file di classe 61 è Java 17, 52 è Java 8: il bytecode del jar prende di mira una JVM più recente rispetto a "java" sul tuo file PATH, quindi la JVM si interrompe prima che DynamoDB Local esegua una singola riga. AWS documenta esplicitamente il piano: v2.6.0+ non funziona su JRE precedenti a 17.

Perché succede

Il sistema java è ancora 8 o 11 — comune su immagini CI e macchine meno recenti su cui è stato installato un LTS JDK anni fa.
JAVA_HOME/PATH punta al vecchio JDK: è installato un JDK più recente, ma la shell risolve prima quello legacy.
Un aggiornamento di DynamoDB Local ha soddisfatto i requisiti: i jar 1.x venivano eseguiti su Java 8; sostituirli con 2.x/3.x ha alzato silenziosamente il livello a 17.
Uno strumento di creazione blocca la toolchain — Maven/Gradle configurato con una vecchia toolchain avvia il DynamoDB Local incorporato sotto di essa.

Quando sono installati più JDK, that java e echo $JAVA_HOME spesso non sono d'accordo — il plugin potrebbe richiamare uno script wrapper che si risolve comunque in Java 11 anche dopo hai installato 17 altrove sul PERCORSO.

Le immagini CI aggiunte a "eclipse-temurin:11" sono una fonte frequente: sposta l'immagine tag su 17 prima del passaggio DynamoDB Local nella pipeline.

Come risolverlo

Controlla cosa è effettivamente in esecuzione:
```
java -version
```

Installa un runtime Java 17+ (qualsiasi distribuzione: Eclipse Temurin, Amazon Corretto, ecc.) e punta la tua shell su di esso:

export JAVA_HOME=/path/to/jdk-17
export PATH="$JAVA_HOME/bin:$PATH"
java -Djava.library.path=./DynamoDBLocal_lib -jar DynamoDBLocal.jar -sharedDb

Oppure elimina il requisito Java locale: l'immagine Docker fornisce un runtime compatibile:
```
docker run -p 8000:8000 amazon/dynamodb-local
```
Aggiorna immagini CI e toolchain: aggiungi Java 17+ ovunque DynamoDB avvii locali (test runner, toolchain Maven/Gradle), in modo che l'errore non si ripresenti per macchina.

Individualo in DynoTable

Salta completamente il JRE locale: esegui docker run -p 8000:8000 amazon/dynamodb-local, installa DynoTable e aggiungi un profilo locale in Impostazioni → Profili → Aggiungi profilo con endpoint http://localhost:8000. Prova connessione conferma che Local è attivo prima di aprire le tabelle. Una volta avviato, il DynamoDB Generatore di espressioni crea bozze di query puoi correre contro l'emulatore.

Errori correlati

DynamoDB Locale: impossibile avviare il processo - altri errori di avvio una volta che Java stesso ha ragione.
DynamoDB Locale: errori sqlite4java — il fratello della libreria nativa.
DynamoDB Locale: porta 8000 in uso
Impara: DynamoDB Locale

Fonti

Distribuzione DynamoDB localmente sul computer — AWS DynamoDB Guida per gli sviluppatori (requisito JRE 17+ per v2.6.0+, comando di avvio, elenco delle versioni)
DynamoDB note sull'utilizzo locale — AWS DynamoDB Guida per gli sviluppatori (-sharedDb e le altre opzioni di runtime)
amazon/dynamodb-local — Docker Hub (l'immagine ufficiale raggruppa un runtime Java compatibile)