Registro de alterações

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