DynoTable

DynamoDB Local: UnsupportedClassVersionError

TL;DR: Su tiempo de ejecución Java es más antiguo que aquel para el que se compiló DynamoDB Local. El DynamoDB Local actual (v2.6.0 y posterior, incluido v3.x) requiere JRE 17+; al iniciarlo el Java 8/11, la JVM rechaza los archivos de clase con UnsupportedClassVersionError. Instale un tiempo de ejecución Java 17+ (Temurin, Corretto,…) y vuelva a ejecutarlo, u omita el Java local por completo con la imagen de Docker amazon/dynamodb-local.

Qué 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

Esto es un Error de la JVM, no una Exception del servicio DynamoDB — el proceso termina antes de que DynamoDB Local ocupe un puerto. La versión de archivo de clase 61 es Java 17 y la 52 es Java 8: el bytecode del jar apunta a una JVM más nueva que el java de tu PATH, así que la JVM aborta antes de que DynamoDB Local ejecute una sola línea. AWS documenta el mínimo de forma explícita: v2.6.0+ no corre en JRE anteriores a 17.

Por qué ocurre

  • El java del sistema sigue siendo 8 u 11 — común en imágenes de CI antiguas y en máquinas donde se instaló un JDK LTS hace años.
  • JAVA_HOME/PATH apuntan al JDK antiguo — hay un JDK más nuevo instalado, pero la shell resuelve primero el heredado.
  • Una actualización de DynamoDB Local cruzó el requisito — los jars 1.x corrían en Java 8; reemplazarlos por 2.x/3.x subió silenciosamente el listón a 17.
  • Una herramienta de build fija el toolchain — Maven/Gradle configurados con un toolchain antiguo lanzan el DynamoDB Local integrado bajo él.

Cuando hay varios JDK instalados, which java y echo $JAVA_HOME suelen no coincidir — el plugin puede invocar un script envoltorio que sigue resolviendo a Java 11 aunque hayas instalado el 17 en otro punto del PATH.

Las imágenes de CI fijadas a eclipse-temurin:11 son una fuente frecuente: sube la etiqueta de la imagen a 17 antes del paso de DynamoDB Local en tu pipeline.

Cómo solucionarlo

  1. Comprueba qué se está ejecutando realmente:

    java -version

  2. Instala un runtime de Java 17+ (cualquier distribución — Eclipse Temurin, Amazon Corretto, etc.) y apunta tu shell a él:

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

  3. O elimina el requisito de Java local — la imagen Docker incluye un runtime compatible:

    docker run -p 8000:8000 amazon/dynamodb-local

  4. Actualiza las imágenes de CI y los toolchains — fija Java 17+ allá donde arranque DynamoDB Local (test runners, toolchains de Maven/Gradle), para que el error no reaparezca por máquina.

Detéctalo en DynoTable

Sáltate el JRE local por completo: ejecuta docker run -p 8000:8000 amazon/dynamodb-local, instala DynoTable y añade un perfil Local en Ajustes → Perfiles → Añadir perfil con el endpoint http://localhost:8000. Probar conexión confirma que Local está en marcha antes de que abras ninguna tabla. Cuando arranque, el DynamoDB Expression Builder redacta las consultas que puedes ejecutar contra el emulador.

Errores relacionados

Fuentes

Trabaja con DynamoDB sin la Consola

Un cliente de escritorio rápido para DynamoDB que ejecuta el SQL real que DynamoDB no puede — JOINs, GROUP BY, agregaciones — con edición visual y un agente de IA con tus propias claves de Bedrock.

DescargarVer precios

Prueba gratuita de 30 días, sin tarjeta — después, el plan Free sin límite de tiempo.