DynamoDB Local: UnsupportedClassVersionError

TL;DR — Your Java runtime is older than the one DynamoDB Local was compiled for. Current DynamoDB Local (v2.6.0 and newer, including v3.x) requires JRE 17+ — launching it on Java 8/11 makes the JVM refuse the class files with UnsupportedClassVersionError. Install a Java 17+ runtime (Temurin, Corretto, …) and re-run, or skip local Java entirely with the amazon/dynamodb-local Docker image.

What it means

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

This is a JVM Error, not a DynamoDB service Exception — the process exits before DynamoDB Local binds a port. Class file version 61 is Java 17, 52 is Java 8 — the jar's bytecode targets a newer JVM than the java on your PATH, so the JVM aborts before DynamoDB Local runs a single line. AWS documents the floor explicitly: v2.6.0+ doesn't run on JREs older than 17.

Why it happens

The system java is still 8 or 11 — common on older CI images and machines where an LTS JDK was installed years ago.
JAVA_HOME/PATH point at the old JDK — a newer JDK is installed, but the shell resolves the legacy one first.
An upgrade of DynamoDB Local crossed the requirement — the 1.x jars ran on Java 8; replacing them with 2.x/3.x silently raised the bar to 17.
A build tool pins the toolchain — Maven/Gradle configured with an old toolchain launches the embedded DynamoDB Local under it.

When multiple JDKs are installed, which java and echo $JAVA_HOME often disagree — the plugin may invoke a wrapper script that still resolves to Java 11 even after you installed 17 elsewhere on the PATH.

CI images pinned to eclipse-temurin:11 are a frequent source — bump the image tag to 17 before the DynamoDB Local step in your pipeline.

How to fix it

Check what's actually running:
```
java -version
```

Install a Java 17+ runtime (any distribution — Eclipse Temurin, Amazon Corretto, etc.) and point your shell at it:

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

Or drop the local Java requirement — the Docker image ships a compatible runtime:
```
docker run -p 8000:8000 amazon/dynamodb-local
```
Update CI images and toolchains — pin Java 17+ wherever DynamoDB Local starts (test runners, Maven/Gradle toolchains), so the error doesn't resurface per machine.

Spot this in DynoTable

Skip the local JRE entirely: run docker run -p 8000:8000 amazon/dynamodb-local, install DynoTable, and add a Local profile in Settings → Profiles → Add Profile with endpoint http://localhost:8000. Test Connection confirms Local is up before you open tables. Once it boots, the DynamoDB Expression Builder drafts queries you can run against the emulator.

DynamoDB Local: unable to start process — other startup failures once Java itself is right.
DynamoDB Local: sqlite4java errors — the native-library sibling.
DynamoDB Local: port 8000 in use
Learn: DynamoDB Local

Sources

Deploying DynamoDB locally on your computer — AWS DynamoDB Developer Guide (the JRE 17+ requirement for v2.6.0+, launch command, version listing)
DynamoDB local usage notes — AWS DynamoDB Developer Guide (-sharedDb and the other runtime options)
amazon/dynamodb-local — Docker Hub (official image bundles a compatible Java runtime)