O Paper pode falhar ao iniciar mesmo depois de você instalar o Java correto porque o painel ou script continua executando outro runtime. Em computadores com várias versões, o comando java depende de PATH e do contexto do processo. Containers, serviços Windows e painéis hospedados podem definir caminhos próprios. A mensagem UnsupportedClassVersionError indica incompatibilidade entre o bytecode exigido e o runtime que abriu o JAR.

Primeiro confirme a versão de Paper e o Java requerido na documentação oficial da versão. Os requisitos mudam com Minecraft; não use uma regra universal baseada na versão mais nova. A página atual do Paper lista faixas diferentes, por exemplo versões recentes de Minecraft podem exigir Java diferente das antigas.

Leia o erro de classe

Uma mensagem de erro pode mostrar “compiled by a more recent version” e informar a versão de classe que o runtime reconhece. Isso geralmente significa Java antigo para o JAR iniciado. Também pode apontar para plugin incompatível se o servidor inicia e só falha ao carregar uma extensão específica. Observe qual classe aparece e em que ponto do log.

Se o Paper em si falha antes da mensagem de carregamento de plugins, verifique o executável e o runtime. Se o erro aparece depois, identifique o JAR responsável e sua versão. Não atualize todos os plugins ou mude argumentos de memória sem saber se o processo principal ou uma extensão causou o erro.

Preserve início completo de latest.log ou saída do console, incluindo o comando de startup se o painel exibir. A primeira exceção costuma ser mais útil que as mensagens finais de encerramento. Anote horário e versão que o painel mostra.

Descubra o Java que o processo realmente usa

Se tem shell na máquina, execute java -version no mesmo usuário, diretório e ambiente usados pelo script de startup. Isso verifica o comando encontrado naquele contexto. Não prova que um painel chamando caminho absoluto ou imagem de container usa o mesmo runtime.

Revise o script: se ele chama java sem caminho, a resolução vem do PATH. Se chama um caminho absoluto, confirme que esse arquivo existe e qual versão executa. Em painel, procure configuração de imagem, variável de ambiente ou seletor Java e veja o comando lançado nos detalhes da instância.

Em Windows, fechar e abrir terminal após mudar PATH pode ser necessário para receber o ambiente novo; serviços já iniciados podem manter valores antigos. Em Linux, um painel como serviço pode herdar PATH diferente do shell do administrador. Em container, atualizar Java no host não troca a imagem usada dentro do container.

Compare requisitos com versão específica

Consulte a tabela do Paper para a versão Minecraft/Paper instalada. Java recomendado é diferente de simplesmente “Java mais recente”; versões preview, early-access ou não suportadas podem apresentar incompatibilidade ou falta de suporte. Use distribuição estável e suportada, evitando pacotes headless que a documentação do Paper não recomenda para suas dependências.

Se o servidor é antigo, plugins compilados para Java mais novo podem falhar mesmo quando o Paper funciona. Revise o requisito do plugin e o runtime comum disponível. Atualizar Java resolve somente uma parte; um plugin também pode exigir API diferente ou ser incompatível com a versão do servidor.

Não faça downgrade de Java em produção sem confirmar requisito e compatibilidade. Um processo que passa a iniciar pode apresentar erro depois no carregamento de plugin ou durante execução. Teste o conjunto completo com cópia do mundo e das configurações.

Corrija ambiente do painel ou container

Em painel gerenciado, selecione a imagem/runtime correspondente à versão do Paper e reinicie a instância. Verifique a saída indicando Java e o caminho do jar. Alguns painéis mantêm template ou startup command separado por servidor; mudar o Java padrão da conta não necessariamente atualiza todas as instâncias.

Em Docker ou outro container, reconstrua ou atualize a imagem que contém Java, depois confirme a versão dentro do container. Não altere o host esperando que o processo encapsulado use o runtime novo. Preserve dados montados em volumes e confirme backup antes de recriar o container.

Em servidor próprio, instale uma distribuição Java suportada e ajuste PATH ou caminho absoluto. Evite apagar outras versões antes de saber se serviços diferentes dependem delas. Para cada instância, mantenha configuração explícita e versionada, reduzindo surpresas após atualização do sistema.

Teste com rollback antes de abrir

Copie o servidor, atualize o runtime da cópia e inicie sem jogadores. Verifique todos os plugins, datapacks, conexão a banco, integração de proxy e salvamento. Execute comandos importantes e faça um desligamento normal. Se o Java mudou major, valide bibliotecas e extensões antigas.

Em produção, faça backup dos mundos, dados externos, arquivos do painel e startup script. Agende janela de manutenção, troque runtime apenas na instância pretendida e acompanhe logs desde o início. Se ocorrer erro novo, restaure a configuração de runtime e preserve o log para comparar.

Não substitua JARs e Java ao mesmo tempo sem necessidade. Separe atualização do servidor de correção do runtime quando possível. Isso ajuda a descobrir se a incompatibilidade vem do bytecode do Paper, plugin, imagem do painel ou mudança de configuração.

Quando o Java está certo, mas o erro continua

Confirme a mensagem com novo log e cheque se o painel realmente usou o runtime selecionado. Se o erro aponta classe de plugin, procure build compatível com sua versão e API. Se aponta bibliotecas externas, confira documentação do plugin e versão Java suportada.

Se o JAR não é uma versão oficial ou veio de fonte incerta, baixe novamente da origem confiável e verifique arquivo. Erro de download truncado ou um JAR que na verdade é página HTML pode produzir falhas diferentes, então não trate qualquer stack trace como Java incorreto.

Ao pedir ajuda, envie a linha completa de erro, versões de Paper e Java efetivas, método de instalação e parte relevante do comando, ocultando caminhos pessoais, tokens e senhas. Evidência concreta evita repetir instalação de Java quando o painel continua executando outro processo.

Evite conflito entre serviços e usuários

Uma máquina pode rodar vários serviços Java com requisitos diferentes: proxy, painel, bot, banco ou mais de uma versão de Minecraft. Não altere o Java global sem verificar quem depende dele. Prefira configurar o runtime por instância ou usar caminhos explícitos, mantendo cada atualização documentada.

Se você instala Java em Windows, confira qual executável aparece primeiro na resolução do PATH e se é uma instalação completa. Em Linux, confirme o caminho para o usuário do serviço e permissões de execução. Não execute o servidor como administrador ou root só para resolver permissão de runtime; ajuste propriedade e acesso de forma adequada.

Depois de uma atualização do sistema, confirme que symlinks e alternativas ainda apontam para a versão escolhida. Um painel pode usar um caminho antigo que foi removido; recriar o link não deve apontar para uma versão incompatível. Faça teste de inicialização e desligamento antes de considerar a manutenção encerrada.

Registre o caminho de inicialização

No runbook da equipe, anote versão de Java, caminho ou imagem usada, Paper, parâmetros de heap e responsável pela atualização. Remova segredos de qualquer exemplo salvo. Assim, outro operador consegue reproduzir o ambiente sem depender de “qual java” encontrado num terminal diferente.

Quando atualizar Minecraft para uma faixa que exige Java novo, planeje Java, Paper e plugins juntos. Leia os avisos de breaking changes, teste um backup do mundo e mantenha rollback compatível com os dados. Trocar o runtime não converte dados do mundo, e voltar apenas o executável pode não desfazer migração já gravada.

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.