UnsupportedClassVersionError significa que o Java responsável por carregar uma classe não suporta a versão de bytecode usada naquela classe. Em um servidor Minecraft, isso pode acontecer com o próprio software do servidor ou com um plugin. A correção começa por identificar qual componente falhou e qual executável Java realmente iniciou o processo.

Não é um erro resolvido aumentando RAM, trocando a seed ou apagando o mundo. Essas mudanças não alteram a capacidade do runtime de carregar a classe. Este guia mostra como investigar a mensagem, conferir o ambiente do painel e corrigir a combinação de versões sem remover dados que não estão envolvidos no problema.

Identifique onde a falha acontece

Guarde o log completo da inicialização e encontre a primeira ocorrência da exceção. Observe a classe indicada e o contexto: o servidor encerrou antes de carregar o mundo ou um plugin falhou enquanto outros continuaram iniciando? Essa distinção orienta qual requisito deve ser conferido primeiro.

Uma classe do software do servidor sugere incompatibilidade entre esse software e o Java usado. Uma classe pertencente a um plugin pode indicar que aquele plugin exige outro Java ou que você baixou uma distribuição incompatível. Não decida somente pelo nome da última linha: leia a mensagem completa e os registros imediatamente anteriores.

A exceção costuma informar uma versão de classe que foi encontrada e a maior versão aceita pelo runtime. Esses números representam o formato do arquivo compilado, não a versão do Minecraft. Registre a mensagem exatamente como apareceu para compará-la com os requisitos do componente.

Confira o requisito da versão instalada

Consulte a documentação correspondente à versão que você pretende executar. No Paper, a tabela oficial de instalação associa linhas do servidor a versões de Java. Não aplique o requisito de uma versão antiga a uma instalação nova nem presuma que todos os loaders e plugins tenham os mesmos requisitos.

Verifique também o arquivo baixado. Confirme projeto, versão, plataforma e origem. Um plugin destinado a um proxy não é automaticamente o arquivo apropriado para Paper. Uma versão de desenvolvimento pode ter requisitos diferentes de uma versão estável que aparece em um tutorial antigo.

O resultado dessa etapa deve ser uma combinação identificada: software e build do servidor, Java exigido e versões dos componentes essenciais. Se uma dependência indispensável não oferece uma versão compatível, a atualização precisa ser planejada como conjunto. Não avance uma parte esperando que as outras carreguem por sorte.

Descubra qual Java o terminal encontra

Em uma máquina administrada por você, execute a consulta no mesmo ambiente que inicia o servidor:

java -version

O resultado mostra o Java encontrado por esse comando. Se a inicialização usa um caminho absoluto, um serviço ou um contêiner, a consulta do terminal pode representar outra instalação. Confira o arquivo de início e o processo configurado. Um terminal recém-aberto também pode ter variáveis diferentes de um serviço que está em execução há vários dias.

No PowerShell, você pode observar os executáveis encontrados pelo comando:

Get-Command java -All

Em Linux, uma consulta simples à resolução do comando é:

command -v java

Essas consultas ajudam a localizar o executável padrão, mas não alteram a configuração do servidor. Se o script usa outro caminho, teste esse caminho com -version. Preserve o arquivo de início antes de editar e confira se a conta do serviço tem acesso à instalação selecionada.

Confira o runtime usado pelo painel

Em hospedagens, o processo pode usar uma imagem ou ambiente Java escolhido na configuração de inicialização. Instalar Java no computador pessoal não modifica o Java do servidor remoto. Procure no painel a opção de runtime, imagem ou versão de Java e compare com o requisito documentado.

Se a opção não estiver disponível, envie ao suporte a mensagem completa, a versão do servidor e o requisito da instalação. Peça para confirmar o runtime usado pelo processo e se existe uma opção compatível com o plano. Isso é mais preciso do que solicitar apenas “atualizar o Java”, sem identificar a versão necessária.

Depois da alteração, pare e inicie o processo pelo procedimento do painel. Uma mudança de configuração que não foi aplicada à nova execução não corrige a instância já iniciada. Leia o começo do novo log para confirmar o ambiente efetivo quando essa informação for exibida.

Corrija o componente certo

Quando o próprio servidor exige um Java diferente, selecione um runtime suportado pela versão instalada e pelas dependências essenciais. Quando apenas um plugin falha, confira se há uma versão desse plugin publicada para a combinação usada pelo projeto. A correção pode ser instalar a distribuição adequada, em vez de mudar todo o ambiente.

Não use flags para tentar ignorar a versão do bytecode. Uma classe que o runtime não consegue interpretar precisa de uma combinação compatível. Também não substitua arquivos internos do JAR nem baixe uma recompilação desconhecida que promete remover o requisito: isso cria novos riscos e dificulta reproduzir a instalação.

Faça o teste primeiro em uma cópia isolada quando o projeto já estiver em produção. A troca de Java pode corrigir a classe inicial e revelar outra incompatibilidade. Observe a inicialização completa, não somente o desaparecimento da primeira exceção.

Verifique o funcionamento após a mudança

  1. Confirme que o processo iniciou com o runtime selecionado.
  2. Leia o log até o fim da inicialização e procure plugins que não carregaram.
  3. Entre com uma conta de teste e execute os recursos essenciais.
  4. Confira dados persistentes, permissões e integrações ligadas ao componente corrigido.
  5. Pare e inicie normalmente para confirmar que a configuração de Java permanece aplicada.

Se surgir outra exceção, registre-a como um problema novo e leia sua causa. Erros de memória, dependências ausentes e configuração inválida não devem ser tratados como se ainda fossem uma falha de versão de classes. Alterar várias opções de uma vez nesse momento perde a clareza obtida na investigação.

Prepare um retorno seguro

Antes de atualizar também o Minecraft ou o software do servidor, faça um backup completo. A troca do runtime sozinha é diferente de uma atualização que converte mundos ou bancos. Se houver conversão, voltar apenas o Java não devolve os dados ao formato anterior.

Guarde as versões que funcionavam e registre a configuração do processo. Se a nova combinação não puder ser aprovada, restaure o conjunto compatível que foi preservado. Não copie um mundo já atualizado para um software antigo sem confirmar se esse retorno é suportado.

Como evitar a repetição do erro

Mantenha uma lista curta com versão do Minecraft, software, Java, loader e componentes fundamentais. Confira esses requisitos antes de cada atualização. Quando a equipe trocar o ambiente do painel, registre a mudança junto da manutenção para que o próximo administrador consiga reproduzir o estado instalado.

Ao abrir um chamado, inclua a classe indicada pela exceção, o log completo revisado para remover segredos, a origem do arquivo e o resultado da consulta ao runtime realmente usado. Essas evidências permitem investigar a incompatibilidade sem exigir tentativas destrutivas no mundo ou nas configurações de jogo.

Fontes e referências

Documentação consultada em 2026-10-08. Os exemplos precisam ser conferidos na versão instalada; este guia não afirma que a configuração foi testada no seu ambiente.