DynoTable

DynamoDB Local: UnsupportedClassVersionError

TL;DR — Seu tempo de execução Java é mais antigo do que aquele para o qual o DynamoDB Local foi compilado. O DynamoDB Local atual (v2.6.0 e mais recente, incluindo v3.x) requer JRE 17+ – iniciá-lo em Java 8/11 faz com que a JVM recuse os arquivos de classe com UnsupportedClassVersionError. Instale um tempo de execução Java 17+ (Temurin, Corretto,…) e execute novamente ou ignore totalmente o Java local com a imagem amazon/dynamodb-local Docker.

O que 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

Isto é um Error da JVM, não uma Exception do serviço DynamoDB — o processo termina antes de o DynamoDB Local vincular uma porta. A versão de arquivo de classe 61 é Java 17, 52 é Java 8 — o bytecode do jar tem como alvo uma JVM mais recente que o java no seu PATH, então a JVM aborta antes de o DynamoDB Local executar uma única linha. A AWS documenta esse piso explicitamente: a v2.6.0+ não roda em JREs anteriores à 17.

Por que isso acontece

  • O sistema java ainda é 8 ou 11 — comum em imagens de CI mais antigas e máquinas onde um LTS JDK foi instalado anos atrás.
  • JAVA_HOME/PATH apontam para o JDK antigo — um JDK mais recente está instalado, mas o shell resolve o legado primeiro.
  • Uma atualização do DynamoDB Local cruzou o requisito — os jars 1.x rodavam em Java 8; substituí-los por 2.x/3.x elevou silenciosamente o piso para 17.
  • Uma ferramenta de build fixa a toolchain — Maven/Gradle configurado com uma toolchain antiga inicia sob ela o DynamoDB Local embutido.

Quando vários JDKs estão instalados, which java e echo $JAVA_HOME costumam discordar — o plugin pode invocar um script wrapper que ainda resolve para Java 11 mesmo depois de você instalar o 17 em outro ponto do PATH.

Imagens de CI fixadas em eclipse-temurin:11 são uma fonte frequente — suba a tag da imagem para 17 antes da etapa do DynamoDB Local no seu pipeline.

Como corrigir

  1. Verifique o que realmente está sendo executado:

    java -version

  2. Instale um runtime Java 17+ (qualquer distribuição — Eclipse Temurin, Amazon Corretto etc.) e aponte seu shell para ele:

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

  3. Ou elimine o requisito de Java local — a imagem Docker já traz um runtime compatível:

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

  4. Atualize as imagens de CI e as toolchains — fixe Java 17+ em todo lugar onde o DynamoDB Local sobe (executores de teste, toolchains Maven/Gradle), para que o erro não reapareça a cada máquina.

Detecte no DynoTable

Pule o JRE local por completo: rode docker run -p 8000:8000 amazon/dynamodb-local, instale o DynoTable e adicione um perfil Local em Configurações → Perfis → Adicionar perfil com o endpoint http://localhost:8000. O Testar conexão confirma que o Local está no ar antes de você abrir tabelas. Assim que ele sobe, o DynamoDB Expression Builder rascunha consultas que você pode rodar contra o emulador.

Erros relacionados

Fontes

Trabalhe com o DynamoDB sem o Console

Um cliente desktop rápido para DynamoDB que roda o SQL de verdade que o DynamoDB não consegue — JOINs, GROUP BY, agregações — com edição visual e um agente de IA com suas próprias chaves do Bedrock.

BaixarVer preços

Teste grátis de 30 dias, sem cartão de crédito — depois o plano Grátis sem limite de tempo.