Registro de alterações

6.0.22 2026-08-26

O empacotamento de uma aplicação Tomcat com JSP agora funciona

• Corrigida a falha de empacotamento com ClassFormatError: Incompatible class format quando um WAR do Tomcat continha páginas JSP. O Protector4J pré-compila as JSP em servlets durante o empacotamento, o que exige um compilador Java e também carregar as classes de manipuladores de tags da própria aplicação. Antes, ambas as coisas aconteciam dentro do processo do Protector4J, onde o runtime incluído (apenas JRE) não oferece compilador e onde as regras de admissão de classes da proteção não permitem carregar classes da aplicação. Agora os dois passos são executados num JDK padrão que o Protector4J obtém sob demanda e mantém em cache local, portanto empacotar uma aplicação JSP já não exige ter um JDK instalado na máquina. O primeiro empacotamento descarrega a cadeia de ferramentas uma vez (cerca de 200 MB); as execuções seguintes reutilizam a cópia em cache.

Editar a configuração de segurança do runtime incluído não quebra mais as aplicações protegidas

• Corrigido: uma aplicação protegida deixava de iniciar depois de o arquivo conf/security/java.security do runtime incluído ser editado — por exemplo para registrar um provedor de segurança (PKCS#11/HSM ou BouncyCastle), desabilitar algoritmos TLS fracos, ligar um modo FIPS ou alterar securerandom.source. O runtime prendia a descriptografia ao conteúdo exato desse arquivo, de modo que qualquer edição impedia abrir o arquivo protegido, com um erro de inicialização obscuro. Esse arquivo é uma configuração que o JDK foi projetado para deixar o operador editar, e alterá-lo nunca ajudou ninguém a contornar a proteção, então prendê-lo não trazia segurança e só criava uma armadilha.
• A identidade do runtime agora é presa apenas aos binários de proteção — o lançador e as bibliotecas nativas centrais —, que é o que de fato impede executar uma aplicação protegida em uma JVM adulterada; o arquivo de política de segurança e um marcador interno de capacidade não fazem mais parte dela. Editar a política de segurança do runtime da maneira habitual agora funciona. Como a identidade do runtime mudou, uma aplicação protegida existente precisa ser codificada novamente com esta versão.

Recursos grandes dentro de JARs de dependência não fazem mais a codificação falhar

• Corrigido: a codificação falhava quando um JAR de dependência em um pacote Tomcat protegido continha um recurso maior que 16 MB — na maioria das vezes o icu4j, cujo arquivo de dados icudt*.dat tem cerca de 25–30 MB e que muitas bibliotecas corporativas trazem de forma transitiva. O empacotador lia cada entrada de cada JAR aninhado na memória sob um limite de 16 MB, embora apenas os arquivos de classe participem da verificação de admissão, de modo que um único arquivo de dados grande abortava toda a compilação. O empacotador agora lê apenas os arquivos de classe e o manifesto e deixa os demais recursos intactos, de modo que essas aplicações são codificadas normalmente e usam menos memória ao fazê-lo.

Aplicações desktop empacotadas como um fat JAR com shade e JxBrowser agora são codificadas

• Corrigido: --native-compat jxbrowser falhava com "no artifacts detected" quando uma aplicação desktop JavaFX/JxBrowser era empacotada como um único fat JAR com shade ou assembly. O scanner reconhecia o JxBrowser apenas pelos nomes de arquivo de seus JARs de dependência independentes, que uma compilação com shade ou assembly achata e elimina. Ele agora identifica o runtime também pelo hash de conteúdo do arquivo Chromium embutido — que uma compilação com shade copia byte a byte —, de modo que as mesmas bibliotecas nativas confiáveis são autorizadas e os dados de admissão em disco ficam idênticos byte a byte ao caminho do JAR independente.

Aplicações com mais de cerca de 1300 classes protegidas agora são codificadas

• Corrigido: a codificação falhava com um "UTF8 string too large" obscuro quando uma aplicação tinha mais de cerca de 1300 classes protegidas. A lista exata dos nomes das classes protegidas era embutida no lançador gerado como uma única constante de string de arquivo de classe, que é limitada a 65535 bytes. A lista agora é entregue como um recurso dentro do pacote e relida em tempo de execução, então o número de classes protegidas não é mais limitado por esse teto; o empacotador também relata um erro claro e acionável se algum valor gerado chegar a se aproximar do limite.

6.0.21 2026-08-25

Aplicações Tomcat grandes e aplicações com muitas dependências falham ao codificar ou iniciar

• A capacidade da lista de admissão do classpath foi aumentada. Um pacote Tomcat protegido registra uma entrada de admissão para cada classe de cada JAR em WEB-INF/lib, e esses metadados eram limitados a 4 MB no total — cerca de 21.000 classes. Uma aplicação web maior atingia esse limite e parava com nested classpath metadata is too large. O limite agora é de 64 MB, e os limites correspondentes por JAR e por classe foram aumentados na mesma proporção, de modo que uma aplicação corporativa típica com dezenas de milhares de classes é codificada normalmente.
• O codificador agora rejeita um pacote que excede a capacidade durante a codificação, informando o que foi excedido, em vez de produzir um arquivo que só falha mais tarde na inicialização. O número de JARs comuns do classpath e o número de arquivos protegidos eram verificados apenas pelo runtime, portanto um pacote Spring Boot no layout separate com muitas dependências, ou uma base Tomcat com muitas aplicações web, podia ser codificado sem problemas e depois não iniciar.
• A forma como o runtime carrega uma lista de admissão grande foi refeita para que a inicialização continue rápida. A lógica anterior crescia com o quadrado do número de classes e teria travado a inicialização de uma aplicação web grande por minutos. As cinco linhas do JDK foram recompiladas com a correção: JDK 25, 21 e 17 para VLX 1.0.24, JDK 11 para VLX 1.0.22 e JDK 8 para VLX 1.0.15.
• A correção abrange tanto o codificador quanto o runtime incluído, portanto uma aplicação protegida existente precisa ser codificada novamente com esta versão para incorporá-la.

Aplicações Spring Boot cujo código de negócio reside inteiramente em JARs de dependência não respondem após a criptografia

• Corrigido: na disposição padrão p4jx-fat, uma aplicação Spring Boot criptografada não expunha nenhum endpoint quando as classes de negócio — controladores, configuração, segurança — ficam dentro dos JARs de dependência em BOOT-INF/lib em vez de em BOOT-INF/classes. A aplicação iniciava, o servidor escutava e o log não mostrava erro algum, mas toda requisição retornava 404 e o Spring Security recorria à sua configuração padrão, porque a varredura de componentes do Spring não via nenhuma classe dentro dos JARs de dependência: o carregador de classes gerado registrava diretórios de pacote apenas para as entradas de BOOT-INF/classes. Isso era independente da criptografia; a mesma disposição falhava estivessem as classes protegidas ou não.
• O carregador p4jx-fat agora registra um diretório de pacote para cada JAR de BOOT-INF/lib e o expõe ao framework por meio de uma URL de JAR aninhado com a mesma forma que o próprio Spring Boot usa, de modo que a varredura de componentes descobre os controladores e a configuração dentro dos JARs de dependência. Com --protect-lib, o stub de metadados agora permanece no JAR de dependência reconstruído em vez de ser projetado em BOOT-INF/classes.

6.0.20 2026-08-22

Falhas aleatórias de aplicações protegidas em todas as linhas de JDK suportadas

• Corrigido um defeito no ambiente de execução incluído que podia terminar uma aplicação protegida de forma aleatória, entre alguns minutos e um dia após o arranque. Quando o compilador JIT descartava o código otimizado e reconstruía um quadro do interpretador, o ambiente lia o operando de uma instrução de chamada de método diretamente da memória sem o desencriptar e usava esse valor sem sentido como índice na cache do conjunto de constantes. O sintoma relatado era um erro fatal da JVM mencionando parameter_size; o mesmo defeito também podia corromper memória alheia sem qualquer erro. As aplicações com caminhos de código quentes muito otimizados eram as mais expostas.
• A auditoria desta mesma classe de defeito nas cinco linhas de JDK revelou mais cinco pontos que liam ou escreviam metadados protegidos sem os descodificar primeiro. Dois deles faziam com que uma verificação interna de coerência terminasse a JVM ao acaso, e outro era uma condição de corrida na ligação de classes que podia devolver um ponteiro de conjunto de constantes inválido enquanto a classe ainda estava a ser preparada. Todos estão corrigidos nos ambientes de execução publicados com esta versão.
• A correção está no ambiente de execução incluído e não no codificador, pelo que uma aplicação protegida existente tem de ser novamente codificada com esta versão para a receber.

Aplicações Spring Boot 4 não arrancavam no JDK 25 com a disposição p4jx-fat

• Corrigido o facto de a disposição p4jx-fat resolver dependências multiversão em relação à versão errada do Java. O empacotador usava a linha de execução escolhida na linha de comandos — que regressa a 21 quando só é passado --jre-home — em vez da versão do ambiente que estava realmente a incluir. Ao empacotar para um ambiente JDK 25 eram assim descartadas todas as entradas a partir de META-INF/versions/22. Com o Spring Framework 7 isso removia ClassFileMetadataReaderFactory, que só existe na variante JDK 24, pelo que todas as aplicações Spring Boot 4 falhavam o arranque com NoClassDefFoundError. As disposições fat e separate nunca foram afetadas, porque mantêm as dependências como ficheiros JAR normais abertos pela própria JVM.

O comando encode volta a funcionar na linha de comandos

• A versão 6.0.19 assinalou a encriptação autónoma de bibliotecas como em desenvolvimento na interface gráfica e, sem intenção, bloqueou também o comando encode na linha de comandos. Esse bloqueio foi removido e encode comporta-se como antes. A interface gráfica mantém o distintivo «Em desenvolvimento», pelo que nada muda desse lado.

Windows ARM64 deixa de ser uma plataforma de destino

• O suporte a windows-aarch64 foi retirado: deixa de ser oferecido na interface gráfica, --target-platform windows-aarch64 é rejeitado, não é gerado nenhum lançador EXE para ele e não é publicado ambiente de execução incluído. O Windows em ARM executa o pacote windows-x64 através da emulação incorporada no sistema operativo. Os destinos suportados são agora macOS em Apple Silicon e Intel, Linux em ARM64 e x64, e Windows em x64 e x86.

6.0.19 2026-08-15

Aviso mais claro de licença de avaliação ao criptografar sem conta

• Quando nenhuma credencial de conta é fornecida, o aviso da CLI agora informa claramente que a aplicação protegida usará uma licença de avaliação e só será executada por 7 dias, e indica https://protector4j.com para a compra de uma licença. Antes, o aviso mencionava apenas "uma licença de avaliação", sem explicar o que isso significava para a aplicação.
• A interface gráfica exibe o mesmo aviso em um diálogo antes de iniciar a criptografia, com três opções: Comprar, Continuar a tarefa e Cancelar a tarefa. O botão de compra abre a página de compra da região de servidor selecionada, de modo que os usuários da região .cn não são enviados ao site .com.

Argumentos de inicialização para abrir a interface gráfica a partir de outras ferramentas

• A interface gráfica agora aceita argumentos de inicialização: p4j-ui [--task-file <file>] [<input-file>]. Um arquivo de tarefa percorre o fluxo normal de importação até a página de confirmação final. Um caminho de entrada comum é pré-preenchido em uma nova tarefa: um .war seleciona automaticamente o fluxo do Tomcat, enquanto um .jar para na página de escolha do tipo de aplicação, pois um JAR pode ser uma aplicação Java, uma aplicação Spring Boot ou uma biblioteca. Esta é a interface de integração para ferramentas externas, como plugins de IDE; argumentos com hífen desconhecidos são ignorados, então iniciar a interface gráfica sem argumentos se comporta exatamente como antes.

Criptografia de biblioteca independente marcada como em desenvolvimento

• A criptografia de biblioteca independente ainda não está disponível na linha 6.x e agora é claramente sinalizada: o cartão correspondente na interface gráfica fica esmaecido com o selo "Em desenvolvimento", e o comando encode da CLI termina com uma mensagem explicativa em vez de iniciar uma tarefa. O recurso será oferecido em uma versão futura.

6.0.18 2026-08-13

Suporte a JAR multiversão no layout p4jx-fat do Spring Boot

• Corrigido um problema em que, no layout p4jx-fat do Spring Boot, as dependências multiversão eram sempre carregadas a partir da versão base. Ao descompactar um JAR aninhado de BOOT-INF/lib, o carregador de classes armazenava as entradas com seus nomes literais, de modo que as classes sob META-INF/versions/ nunca eram selecionadas e o retorno à versão base sempre prevalecia. Um sintoma concreto: com o Spring Framework 7.0.5, VirtualThreadDelegate era resolvido para o stub da versão base, que lança incondicionalmente uma UnsupportedOperationException; por isso, uma aplicação executada no JDK 25 com spring.threads.virtual.enabled=true não iniciava. Muitas dependências de uso comum são distribuídas como JAR multiversão, portanto outros caminhos de código específicos de versão eram afetados da mesma forma.
• Agora o carregador de classes resolve as entradas multiversão no momento do carregamento, escolhendo a versão mais alta suportada pelo JDK em execução, e o empacotador aplica a mesma resolução ao construir o índice de recursos fat, de modo que o índice e o carregador sempre concordam sobre qual entrada prevalece. Os outros dois layouts, fat e separate, nunca foram afetados, pois mantêm as dependências como arquivos JAR comuns abertos pela própria JVM.

6.0.17 2026-08-13

Correção da inicialização de aplicações protegidas em caminhos do Windows com caracteres não ASCII

• Corrigida a falha de inicialização de aplicações protegidas no Windows quando o caminho continha caracteres não ASCII, por exemplo chineses. Dependendo de onde o caminho era lido incorretamente, a inicialização falhava com o erro de arquivo E816 ou com uma falha de descriptografia que aparecia como ClassFormatError. O runtime abria o arquivo e normalizava os caminhos byte a byte, de modo que um caractere codificado em uma página de código legada cujo segundo byte é justamente 0x5C — a barra invertida — era partido ao meio, e sua parte final era lida como separador de diretórios. No GBK, muitos caracteres chineses de uso cotidiano são codificados assim. Caminhos formados apenas por caracteres ASCII nunca foram afetados.
• No Windows, o runtime agora converte os caminhos para caracteres largos por meio da página de código ANSI do sistema antes de abrir arquivos e antes de calcular a impressão digital do runtime, exatamente como o JDK original sempre abriu arquivos. Apenas o caminho de código do Windows mudou; Linux e macOS continuam se comportando como antes. As cinco linhas de JDK foram reconstruídas com a correção: JDK 25, 21 e 17 para VLX 1.0.22, JDK 11 para VLX 1.0.20 e JDK 8 para VLX 1.0.13.

6.0.16 2026-08-10

Correção do empacotamento no Windows para destinos Linux e macOS

• Corrigida uma falha de empacotamento no Windows quando a plataforma de destino é Linux ou macOS. A extração do runtime incluído relatava Failed to extract P4JX runtime mesmo que o runtime tivesse sido extraído corretamente. O Windows não consegue criar links simbólicos sem privilégios elevados, e os runtimes de Linux e macOS contêm pouco mais de uma centena deles em legal/ — textos de licença que o jlink aponta para java.base em vez de duplicar. O comando tar que acompanha o Windows trata isso como aviso, mas ainda assim retorna um código de saída diferente de zero, que o codificador interpretava como falha definitiva e em seguida apagava o runtime já extraído. O empacotamento no Windows para um destino Windows nunca foi afetado, porque os runtimes do Windows não contêm nenhum link simbólico.
• O tratamento de arquivos já não depende do comando tar da plataforma. O codificador agora lê e extrai por conta própria os runtimes .tar.gz e os recursos do JavaFX, de modo que o comportamento é idêntico no Windows, Linux e macOS. As permissões de arquivo, incluindo o bit de execução do inicializador, vêm do próprio arquivo e não do sistema de arquivos do host. No Windows os links simbólicos de licença são ignorados: eles não têm função em tempo de execução nem fazem parte da impressão digital do runtime, portanto as aplicações protegidas no Windows são descriptografadas exatamente como antes.

6.0.15 2026-08-08

Correções da caixa de diálogo de atualização

• A caixa de diálogo "Nova versão" agora abre com um tamanho fixo e razoável, em vez de ocupar a tela inteira quando o changelog é longo.
• Adicionada a opção "Verificar atualizações" à barra de ferramentas, permitindo verificar uma versão mais recente a qualquer momento, não apenas na inicialização.

6.0.14 2026-08-07

Criptografia inline de constantes de string, agora o padrão

• Foi adicionado um modo de proteção de strings inline que reescreve as instruções ldc de carregamento de string em uma chamada a um método de descriptografia sintético próprio de cada classe, removendo por completo do pool de constantes o texto simples de uma constante de string. O texto simples deixa de entrar na SymbolTable ao carregar a classe, aparece no heap apenas quando esse código é de fato executado, e as strings não utilizadas permanecem criptografadas. O texto cifrado trafega dentro do corpo da classe e é coberto pela criptografia por método existente. É uma transformação de bytecode puramente do lado do codificador: o formato de arquivo e o runtime permanecem inalterados e funciona em todas as linhas de JDK suportadas sem atualização de runtime.
• A proteção de strings agora é uma única opção com três modos — Nenhum, Padrão (pool de constantes V72) e Inline — e Inline é o padrão para todos os tipos de aplicação, incluindo o Tomcat. Foi validada de ponta a ponta em servlets comuns, lógica de negócio com switch sobre strings e classes de servlet JSP pré-compiladas pelo JspC. A opção da CLI é --encrypt-strings none|constant|inline, e a interface gráfica oferece a mesma escolha.
• Um método que não pode ser reescrito — uma interface em um formato antigo de arquivo de classe, um método próximo do limite de 64 KB ou um raro caso limite de serialização — recai na camada padrão V72, de modo que o resultado nunca é mais fraco do que antes.

Inicialização mais rápida do Spring Boot p4jx-fat

• O carregador de classes do Spring Boot em pure-fat agora lê seu índice de recursos aninhados sob demanda em vez de antecipadamente, reduzindo o trabalho de inicialização de grandes aplicações p4jx-fat.

Credenciais de conta a partir de variáveis de ambiente

• Os comandos encode, javaapp, springboot e tomcat e o modo de arquivo de tarefa agora podem ler o e-mail e a senha da conta de P4JX_ACCOUNT_EMAIL e P4JX_ACCOUNT_PASSWORD (ou P4JX_ACCOUNT_PASSWORD_MD5), usados apenas quando a opção de linha de comando correspondente está ausente, de modo que um arquivo de tarefa exportado permaneça sem credenciais.

6.0.13 2026-08-05

Correção de inicialização para aplicações protegidas que usam javax.lang.model

• Corrigido NoClassDefFoundError: javax/lang/model/SourceVersion na inicialização de aplicações protegidas cujos frameworks referenciam a API javax.lang.model — em especial o Spring Data JPA, cujo repository AOT processor acessa SourceVersion durante a inicialização do contêiner. O módulo java.compiler, antes removido do runtime empacotado, voltou a ser incluído. É um módulo apenas de API, sem implementação de compilador, portanto ToolProvider.getSystemJavaCompiler() continua retornando null e jdk.compiler permanece ausente — a superfície de proteção não muda.
• Os runtimes de JDK 17, 21 e 25 são reconstruídos para VLX 1.0.21, e o JDK 11 para VLX 1.0.19, todos com o módulo java.compiler restaurado. O JDK 8 não é afetado porque não tem sistema de módulos e já fornece essas classes.

6.0.12 2026-08-02

Suporte ao JxBrowser 9 e correção de falha em aplicações protegidas que lançam NullPointerException

• As aplicações protegidas agora podem incorporar o JxBrowser 9. --native-compat jxbrowser seleciona uma das nove versões do catálogo interno, da 9.0.0 à 9.3.1, em sete plataformas com Java 17, 21 e 25. O runtime concede permissão de anexação de thread apenas à biblioteca IPC oficial cujo SHA-256 está registrado para a versão escolhida e verifica novamente o módulo chamador no momento em que uma thread realmente se anexa. Caminhos, hashes e nomes de biblioteca nunca são aceitos pela linha de comando. No macOS 26, use o JxBrowser 9.0.1 ou posterior: a TeamDev corrigiu nessa versão uma falha do Chromium ao criar o Engine, e a 9.0.0 também falha nesse sistema com um JDK comum.
• Corrigido o ClassFormatError em aplicações protegidas que lançam uma NullPointerException. A correção da 6.0.9 suprimia a mensagem NPE detalhada da JVM método a método, o que se mostrou insuficiente: esse recurso analisa os corpos dos métodos como bytecode padrão e, depois que o P4JX os transforma, nenhum indicador por método pode comprovar que essa análise continua válida. O runtime agora desativa a mensagem detalhada incondicionalmente. O tipo da exceção, o rastreamento de pilha e qualquer mensagem fornecida pela aplicação não são afetados. Os runtimes de JDK 17, 21 e 25 foram reconstruídos como VLX 1.0.20; o JDK 11 não é afetado e permanece na VLX 1.0.18, e o JDK 8 permanece na VLX 1.0.12.
• O java -version agora informa a compilação do runtime VLX, permitindo identificar o runtime incluído sem descompactá-lo.
• Os dois campos de versão do EXE do Windows passam a ser validados antes do início do empacotamento, em vez de falhar no meio do processo. O Windows armazena cada componente como um inteiro sem sinal de 16 bits, portanto cada um dos um a quatro números separados por pontos deve ficar entre 0 e 65535. Deixar os campos vazios continua significando 0.0.0.0.

6.0.11 2026-07-27

Inicializadores nativos do Windows para aplicações protegidas

• Foi adicionada a geração opcional de EXE nativo do Windows para pacotes Java App, os três layouts do Spring Boot e pacotes Tomcat. Há inicializadores de console e GUI para Windows x64, x86 e ARM64, e os scripts de inicialização existentes continuam presentes em todos os pacotes.
• Foram adicionadas configurações na CLI e na interface gráfica para o nome do EXE, modo, ícone e metadados de versão do Windows. Tarefas multiplataforma geram um EXE somente para os destinos Windows selecionados, e as configurações são preservadas na versão 2 de p4j-task.yml; arquivos de tarefa da versão 1 continuam legíveis.
• O inicializador JExeKit, implementado inteiramente em Win32, foi integrado ao vlxjre incluído, ao classpath exato e aos argumentos da JVM. Antes de iniciar o Java, os inicializadores rejeitam caminhos que saiam do pacote, substituições por pontos de nova análise e opções inseguras de agente ou boot classpath.
• Os modelos do JExeKit são incorporados somente como recursos .jxt criptografados com AES-GCM e descriptografados na memória durante a geração. Cada inicializador gerado contém uma assinatura Ed25519 com status de produção sobre seu bloco de parâmetros; as alterações de ícone, versão, manifesto e parâmetros terminam antes da assinatura Authenticode final do usuário.

6.0.10 2026-07-27

Carregamento mais rápido das dependências do Tomcat sem alterar a estrutura do WAR

• Foram corrigidas lentidões graves na inicialização do Tomcat causadas pela releitura e pelo cálculo do hash de um JAR aninhado protegido inteiro em WEB-INF/lib sempre que uma classe era carregada. O VLX 1.0.17 agora verifica cada JAR aninhado selado apenas uma vez, mantém em cache sua procedência autenticada dentro da VM e continua validando cada classe solicitada em relação ao índice de classes criptografado.
• Foi removida a solução temporária que extraía e montava web-libs. Os arquivos WEB-INF/lib/*.jar permanecem no arquivo .p4jx protegido, preservando a estrutura WAR original e o isolamento dos aplicativos. Os runtimes VLX 1.0.17 para JDK 11, 17, 21 e 25 foram publicados para 24 combinações de plataformas compatíveis. O JDK 8 mantém seu caminho ZIP overlay existente e continua no VLX 1.0.11.
• Foi corrigida a verificação de compatibilidade do module-info.class do aplicativo. Os descritores de módulo não contêm corpos de métodos e agora são excluídos automaticamente da criptografia, permanecendo legíveis pelas ferramentas de descritores.
• Os comandos CLI exportados pela interface gráfica agora podem colocar --java-version, --target-platform e --create-new-folder após os argumentos do empacotador como um sufixo contínuo. A forma de prefixo existente continua compatível.

6.0.9 2026-07-25

Correção de falha para aplicativos criptografados que exibem NullPointerException

• Corrigida uma falha da JVM que podia ocorrer quando um método protegido lançava uma NullPointerException implícita e o aplicativo lia sua mensagem ou imprimia seu rastreamento de pilha. O recurso de "detalhe útil de NPE" do runtime tentava reconstruir o texto "because ... is null" a partir do bytecode criptografado do método, acessava memória inválida e travava a VM (observado em aplicativos JavaFX FXML). Os métodos protegidos agora ignoram a mensagem detalhada e recorrem a uma NullPointerException padrão; o tipo da exceção, o rastreamento de pilha e qualquer mensagem fornecida pelo aplicativo não são afetados.
• Os runtimes para JDK 17, 21 e 25 são reconstruídos para VLX 1.0.16 com esta correção. O JDK 11 não é afetado porque o recurso de NPE útil não existe antes do JDK 14 e permanece em VLX 1.0.15; o JDK 8 permanece em VLX 1.0.11.

6.0.8 2026-07-24

Runtimes do Tomcat baixados sob demanda e padrões seguros para produção

• Foi corrigida a falha do codificador autoprotegido publicado ao empacotar WARs do Tomcat, pois as classes do Tomcat dentro de app.p4jx deixaram de ser visíveis como um JAR físico do classpath. O Tomcat 9.0.107 e o 10.1.53 agora são artefatos R2/COS imutáveis e versionados, selecionados de acordo com o namespace de Servlet, baixados no primeiro uso, armazenados no cache local e verificados por um SHA-256 exato e pelo manifesto dos JARs. Caches adulterados são descartados e baixados novamente.
• Os JARs públicos de WEB-INF/lib agora são disponibilizados como recursos Web físicos, isolados por aplicação e vinculados por hash. Isso evita a leitura e a verificação repetidas do arquivo aninhado para cada classe durante a inicialização do Spring.
• As novas compilações agora usam por padrão o endpoint de licença de produção https://protector4j.com. O endpoint interno http://10.10.10.16:16002 só é usado quando P4JX_LICENSE_MODE=dev ou -PlicenseMode=dev é selecionado explicitamente.

6.0.7 2026-07-24

Dependências aninhadas do Tomcat e classes dinâmicas confiáveis

• Foram corrigidas as falhas de WARs protegidos do Tomcat ao carregar classes ou serviços de WEB-INF/lib/*.jar. O Protector4J agora sela em app.p4jx os metadados SHA-256 exatos dos JARs e das classes aninhados; dependências desconhecidas, substituídas ou adulteradas continuam sendo rejeitadas.
• Foram corrigidas as falhas do Spring CGLIB e do Hibernate Byte Buddy no JDK 11 causadas pelo marcador de origem específico do JDK 11 usado por MethodHandles.Lookup#defineClass. A confiança dinâmica ainda exige a proveniência da classe chamadora ou do carregador verificada pela VM; strings de marcador, nomes de classe, caminhos, pacotes e CodeSource não concedem confiança.
• Foram publicados runtimes VLX 1.0.15 para JDK 11, 17, 21 e 25 em 24 combinações de plataformas compatíveis. Todos passaram pelos controles rigorosos L1-L5, incluindo FXML real, Swing/AWT, carregamento de dependências aninhadas do Tomcat e casos negativos de proveniência e adulteração. O JDK 8 permanece no VLX 1.0.11.

6.0.6 2026-07-22

Proveniência confiável da definição de classes

• Foram corrigidas as falhas de inicialização de aplicações JavaFX FXML protegidas: MethodUtil define o helper Trampoline, cuja proveniência foi verificada pela VM, por meio de defineClass(byte[]). A confiança agora só se propaga a partir da proveniência de classe ou carregador verificada pela VM, não de nomes de classe, caminhos, pacotes ou strings CodeSource.
• Foi adicionada cobertura FXML real com fx:controller, elementos de propriedade, injeção de Controller e inicialização do WebView, além de regressões para definições dinâmicas confiáveis, propagação em dois níveis, fontes desconhecidas, JARs não autorizados e substituição de nomes protected class.
• Foram publicados runtimes VLX 1.0.14 para JDK 11, 17, 21 e 25. O JDK 8 permanece em VLX 1.0.11.

6.0.5 2026-07-21

Integridade do ambiente de execução nativo do JavaFX

• Foram corrigidas as falhas de inicialização do JavaFX WebView no Windows (Graphics Device initialization failed / No toolkit found) colocando as DLLs empacotadas do JavaFX em vlxjre/bin e ajustando a busca por bibliotecas nativas do iniciador.
• A lista de permissões criptografada de app.p4jx foi ampliada para incluir bibliotecas nativas externas. Os arquivos nativos do JavaFX devem corresponder exatamente aos valores SHA-256, independentemente do caminho, e o Glass revalida o arquivo realmente carregado; arquivos não reconhecidos ou adulterados são rejeitados.
• Foram publicados ambientes de execução Protector4J atualizados para JDK 11, 17, 21 e 25. As combinações de plataformas JavaFX compatíveis passaram pelo L5.1-L5.4, que cobre a inicialização do WebView e a rejeição de módulos JAR, jdk.jsobject e bibliotecas nativas do Glass adulterados.

6.0.4 2026-07-21

Integridade de módulos externos e compatibilidade do runtime JavaFX

• Foi removida a confiança baseada em caminho para módulos externos. Agora, cada JAR de módulo externo deve corresponder exatamente a uma entrada SHA-256 da lista de permissões incorporada em app.p4jx; arquivos não reconhecidos ou adulterados são rejeitados independentemente da localização.
• Foi adicionada a detecção automática do fechamento de dependências a partir de JavaFX module-info.class e a admissão controlada de módulos JavaFX e JDK fixados, incluindo javafx.media e jdk.jsobject.
• Foram corrigidos os problemas de inicialização do JavaFX WebView e os erros E818 / ClassFormatError após a camada de inicialização nas versões de JDK e plataformas compatíveis com os novos runtimes P4JX.

6.0.3 2026-07-20

Compatibilidade do módulo JavaFX WebView

• Corrigida a resolução do módulo opcional jdk.jsobject para runtimes P4JX compatíveis reconstruídos a partir da mesma versão de JDK/VLX. Um runtime compatível não é mais rejeitado apenas porque a imagem completa lib/modules contém bytes diferentes.
• Permanecem a seleção de artefatos por linha do JDK e plataforma, a validação exata do SHA-256 e do nome do módulo e a nova verificação do fechamento das dependências após a instalação.

6.0.2 2026-07-20

Compatibilidade com JavaFX WebView

• Corrigidas as falhas de inicialização do JavaFX WebView ao empacotar javafx.media junto com javafx.web e resolver automaticamente o módulo jdk.jsobject que corresponde exatamente ao P4JX quando ele não está presente em um runtime reduzido.
• Adicionados downloads de módulos opcionais fixados por SHA-256 e vinculados à versão, plataforma e runtime por meio do serviço público regional. Runtimes que já contêm o módulo ignoram o download.

6.0.1 2026-07-20

Compatibilidade com JavaFX

• Foram corrigidas as falhas de inicialização de fat JARs que incorporam classes do runtime JavaFX. A aplicação automática de compatibilidade agora mantém sem criptografia os namespaces da API, da implementação e da ponte JNI do JavaFX incorporado, evitando a atribuição duplicada com os módulos JavaFX empacotados.
• Foram aprimorados os diagnósticos de compatibilidade e as orientações multilíngues para aplicações com runtimes JavaFX incorporados.

6.0.0 2026-07-20

O Protector4J 6.0 é uma versão principal baseada em uma arquitetura de proteção totalmente reformulada, e não uma atualização incremental comum da série 5.x.

Arquitetura e proteção

• Reformulação da arquitetura fundamental do Protector4J e introdução do novo mecanismo de proteção P4JX.
• Adição de quase 100 medidas de proteção na geração de arquivos, no carregamento de classes, na execução, na proteção contra depuração e na integridade dos artefatos.
• Aumento significativo da barreira contra engenharia reversa. A nova arquitetura foi projetada para tornar a quebra em curto prazo extremamente difícil, mesmo com ferramentas avançadas de análise assistida por IA.
• Reforço das solicitações de licença, dos downloads de runtimes, da verificação de artefatos e da segurança dos instaladores multiplataforma.

Experiência do produto

• Suporte para JDK 8, 11, 17, 21 e 25, com fluxos gráficos de empacotamento para aplicações Java, JavaFX, Spring Boot e Tomcat.
• Adição de verificação de compatibilidade, criptografia seletiva de classes, proteção de JARs de dependências, importação/exportação de tarefas YAML e compilações em lote para várias plataformas de destino.
• Reformulação da interface para desktop, agora com suporte a 11 idiomas e preferência de idioma persistente.

Notas de migração

O uso do Protector4J 6.0 difere significativamente das versões anteriores. Antes de utilizá-lo, releia a documentação mais recente e recompile e migre suas aplicações criptografadas para a versão 6.0 assim que possível, a fim de aproveitar a proteção mais robusta.

Baixar o Protector4J 6.0

Versões anteriores