Registro de cambios

6.0.12 2026-08-02

Compatibilidad con JxBrowser 9 y corrección de un fallo en aplicaciones protegidas que lanzan NullPointerException

• Las aplicaciones protegidas ya pueden incorporar JxBrowser 9. --native-compat jxbrowser selecciona una de las nueve versiones del catálogo integrado, de la 9.0.0 a la 9.3.1, en siete plataformas con Java 17, 21 y 25. El entorno de ejecución concede el permiso de asociación de hilos únicamente a la biblioteca IPC oficial cuyo SHA-256 está registrado para la versión elegida, y vuelve a comprobar el módulo llamante cuando un hilo se asocia realmente. Nunca se aceptan rutas, hashes ni nombres de biblioteca desde la línea de comandos. En macOS 26, utilice JxBrowser 9.0.1 o posterior: TeamDev corrigió en esa versión un fallo de Chromium al crear el Engine, y la 9.0.0 también falla allí con un JDK normal.
• Corregido el ClassFormatError en aplicaciones protegidas que lanzan una NullPointerException. La corrección de 6.0.9 suprimía el mensaje NPE detallado de la JVM método a método, lo que resultó insuficiente: esa función analiza los cuerpos de los métodos como bytecode estándar y, una vez que P4JX los ha transformado, ningún indicador por método puede demostrar que ese análisis siga siendo válido. El entorno de ejecución ahora desactiva el mensaje detallado de forma incondicional. El tipo de excepción, la traza de pila y cualquier mensaje proporcionado por la aplicación no se ven afectados. Los entornos de ejecución de JDK 17, 21 y 25 se han reconstruido como VLX 1.0.20; JDK 11 no está afectado y permanece en VLX 1.0.18, y JDK 8 permanece en VLX 1.0.12.
• java -version ahora indica la compilación del entorno de ejecución VLX, de modo que se puede identificar el entorno incluido sin descomprimirlo.
• Los dos campos de versión del EXE de Windows se validan ahora antes de iniciar el empaquetado, en lugar de fallar a mitad del proceso. Windows almacena cada componente como un entero sin signo de 16 bits, por lo que cada uno de los uno a cuatro números separados por puntos debe estar entre 0 y 65535. Dejar los campos vacíos sigue significando 0.0.0.0.

6.0.11 2026-07-27

Lanzadores nativos de Windows para aplicaciones protegidas

• Se añadió la generación opcional de EXE nativos de Windows para paquetes Java App, los tres diseños de Spring Boot y paquetes Tomcat. Hay lanzadores de consola y GUI para Windows x64, x86 y ARM64, y los scripts de inicio existentes se mantienen en todos los paquetes.
• Se añadieron opciones en la CLI y la interfaz gráfica para el nombre del EXE, el modo, el icono y los metadatos de versión de Windows. Las tareas multiplataforma solo generan un EXE para los destinos Windows seleccionados, y la configuración se conserva en la versión 2 de p4j-task.yml; los archivos de tareas de la versión 1 siguen siendo legibles.
• Se integró el lanzador JExeKit, basado exclusivamente en Win32, con el vlxjre incluido, el classpath exacto y los argumentos de la JVM. Antes de iniciar Java, los lanzadores rechazan rutas que salgan del paquete, sustituciones mediante puntos de reanálisis y opciones inseguras de agentes o del boot classpath.
• Las plantillas de JExeKit solo se incluyen como recursos .jxt cifrados con AES-GCM y se descifran en memoria durante la generación. Cada lanzador generado incorpora una firma Ed25519 con estado de producción sobre su bloque de parámetros; los cambios de icono, versión, manifiesto y parámetros finalizan antes de la firma Authenticode definitiva del usuario.

6.0.10 2026-07-27

Carga más rápida de dependencias de Tomcat sin alterar la estructura del WAR

• Se corrigieron ralentizaciones graves durante el inicio de Tomcat causadas por volver a leer y calcular el hash de un JAR anidado protegido completo dentro de WEB-INF/lib cada vez que se cargaba una clase. VLX 1.0.17 ahora verifica una sola vez cada JAR anidado sellado, almacena en caché su procedencia autenticada dentro de la VM y continúa validando cada clase solicitada contra el índice de clases cifrado.
• Se eliminó la solución temporal que extraía y montaba web-libs. Los archivos WEB-INF/lib/*.jar permanecen dentro del archivo .p4jx protegido, conservando la estructura WAR original y el aislamiento de las aplicaciones. Se publicaron runtimes VLX 1.0.17 para JDK 11, 17, 21 y 25 en 24 combinaciones de plataformas compatibles. JDK 8 conserva su ruta ZIP overlay existente y permanece en VLX 1.0.11.
• Se corrigió el análisis de compatibilidad de module-info.class de la aplicación. Los descriptores de módulos no contienen cuerpos de métodos, por lo que ahora se excluyen automáticamente del cifrado y siguen siendo legibles para las herramientas de descriptores.
• Los comandos CLI exportados por la interfaz gráfica ahora pueden colocar --java-version, --target-platform y --create-new-folder después de los argumentos del empaquetador como un sufijo continuo. El formato de prefijo existente sigue siendo compatible.

6.0.9 2026-07-25

Corrección de fallo para aplicaciones cifradas que muestran NullPointerException

• Se corrigió un fallo de la JVM que podía ocurrir cuando un método protegido lanzaba una NullPointerException implícita y la aplicación leía su mensaje o imprimía su traza de pila. La función de "detalle útil de NPE" del runtime intentaba reconstruir el texto "because ... is null" a partir del bytecode cifrado del método, accedía a memoria no válida y hacía que la VM fallara (observado con aplicaciones JavaFX FXML). Los métodos protegidos ahora omiten el mensaje detallado y recurren a una NullPointerException estándar; el tipo de excepción, la traza de pila y cualquier mensaje proporcionado por la aplicación no se ven afectados.
• Los runtimes para JDK 17, 21 y 25 se reconstruyen a VLX 1.0.16 con esta corrección. JDK 11 no se ve afectado porque la función de NPE útil no existe antes de JDK 14 y permanece en VLX 1.0.15; JDK 8 permanece en VLX 1.0.11.

6.0.8 2026-07-24

Runtimes de Tomcat descargados bajo demanda y valores predeterminados seguros para producción

• Se corrigió el fallo del codificador autoprotegido publicado al empaquetar WAR de Tomcat, ya que las clases de Tomcat dentro de app.p4jx ya no eran visibles como un JAR físico del classpath. Tomcat 9.0.107 y 10.1.53 son ahora artefactos R2/COS inmutables y versionados, seleccionados según el espacio de nombres de Servlet, descargados en el primer uso, almacenados en la caché local y verificados mediante un SHA-256 exacto y el manifiesto de JAR. Las cachés manipuladas se descartan y se vuelven a descargar.
• Los JAR públicos de WEB-INF/lib ahora se despliegan como recursos web físicos, aislados por aplicación y vinculados por hash. Así se evita leer y verificar repetidamente el archivo anidado para cada clase durante el inicio de Spring.
• Las nuevas compilaciones ahora usan de forma predeterminada el endpoint de licencias de producción https://protector4j.com. El endpoint interno http://10.10.10.16:16002 solo se usa cuando se selecciona explícitamente P4JX_LICENSE_MODE=dev o -PlicenseMode=dev.

6.0.7 2026-07-24

Dependencias anidadas de Tomcat y clases dinámicas fiables

• Se corrigieron los fallos de los WAR de Tomcat protegidos al cargar clases o servicios desde WEB-INF/lib/*.jar. Protector4J ahora sella en app.p4jx los metadatos SHA-256 exactos de los JAR y las clases anidados; las dependencias desconocidas, sustituidas o manipuladas se siguen rechazando.
• Se corrigieron los fallos de Spring CGLIB y Hibernate Byte Buddy en JDK 11 causados por el marcador de origen específico de JDK 11 que usa MethodHandles.Lookup#defineClass. La confianza dinámica sigue requiriendo una procedencia de la clase invocadora o del cargador verificada por la VM; las cadenas de marcadores, los nombres de clase, las rutas, los paquetes y CodeSource no otorgan confianza.
• Se publicaron runtimes VLX 1.0.15 para JDK 11, 17, 21 y 25 en 24 combinaciones de plataformas compatibles. Todos superaron los controles estrictos L1-L5, incluidos FXML real, Swing/AWT, carga de dependencias anidadas de Tomcat y casos negativos de procedencia y manipulación. JDK 8 permanece en VLX 1.0.11.

6.0.6 2026-07-22

Procedencia fiable de la definición de clases

• Se corrigieron los fallos de inicio de aplicaciones JavaFX FXML protegidas: MethodUtil define su helper Trampoline, cuya procedencia fue verificada por la VM, mediante defineClass(byte[]). La confianza ahora solo se propaga desde la procedencia de clases o cargadores verificada por la VM, no desde nombres de clase, rutas, paquetes ni cadenas CodeSource.
• Se añadió cobertura FXML real con fx:controller, elementos de propiedad, inyección de Controller e inicio de WebView, además de regresiones para definiciones dinámicas fiables, propagación en dos niveles, fuentes desconocidas, JAR no autorizados y sustitución de nombres protected class.
• Se publicaron runtimes VLX 1.0.14 para JDK 11, 17, 21 y 25. JDK 8 permanece en VLX 1.0.11.

6.0.5 2026-07-21

Integridad del entorno de ejecución nativo de JavaFX

• Se corrigieron los fallos de inicio de JavaFX WebView en Windows (Graphics Device initialization failed / No toolkit found) colocando las DLL de JavaFX empaquetadas en vlxjre/bin y ajustando la búsqueda de bibliotecas nativas del lanzador.
• La lista de permisos cifrada de app.p4jx se amplió para incluir bibliotecas nativas externas. Los archivos nativos de JavaFX deben coincidir exactamente con los valores SHA-256 independientemente de la ruta, y Glass vuelve a validar el archivo cargado; los archivos no reconocidos o modificados se rechazan.
• Se publicaron entornos de ejecución Protector4J actualizados para JDK 11, 17, 21 y 25. Las combinaciones de plataformas JavaFX compatibles superaron L5.1-L5.4, que cubren el inicio de WebView y el rechazo de módulos JAR, jdk.jsobject y bibliotecas nativas de Glass modificados.

6.0.4 2026-07-21

Integridad de módulos externos y compatibilidad del entorno de ejecución JavaFX

• Se eliminó la confianza basada en rutas para los módulos externos. Ahora, cada JAR de módulo externo debe coincidir exactamente con una entrada SHA-256 de la lista de permitidos incluida en app.p4jx; los archivos no reconocidos o modificados se rechazan independientemente de su ubicación.
• Se agregó la detección automática del cierre de dependencias a partir de JavaFX module-info.class y la admisión controlada de módulos JavaFX y JDK fijados, incluidos javafx.media y jdk.jsobject.
• Se corrigieron los fallos de inicio de JavaFX WebView y los errores E818 / ClassFormatError posteriores a la capa de arranque en las versiones de JDK y plataformas compatibles mediante los nuevos entornos de ejecución P4JX.

6.0.3 2026-07-20

Compatibilidad del módulo JavaFX WebView

• Se corrigió la resolución del módulo opcional jdk.jsobject para runtimes P4JX compatibles reconstruidos desde la misma versión de JDK/VLX. Un runtime compatible ya no se rechaza únicamente porque la imagen completa lib/modules tenga bytes diferentes.
• Se mantienen la selección de artefactos por línea de JDK y plataforma, la validación exacta del SHA-256 y del nombre del módulo, y la comprobación del cierre de dependencias después de la instalación.

6.0.2 2026-07-20

Compatibilidad con JavaFX WebView

• Se corrigieron los fallos de inicio de JavaFX WebView empaquetando javafx.media junto con javafx.web y resolviendo automáticamente el módulo jdk.jsobject que coincide exactamente con P4JX cuando no está incluido en un entorno de ejecución reducido.
• Se añadieron descargas de módulos opcionales fijadas por SHA-256 y vinculadas a la versión, la plataforma y el entorno de ejecución desde el servicio público regional. Los entornos que ya incluyen el módulo omiten la descarga.

6.0.1 2026-07-20

Compatibilidad con JavaFX

• Se corrigieron los fallos de inicio de los fat JAR que incorporan clases del runtime de JavaFX. La aplicación automática de compatibilidad mantiene ahora sin cifrar los espacios de nombres de la API, la implementación y el puente JNI de JavaFX incorporados, lo que evita una asignación duplicada con los módulos JavaFX empaquetados.
• Se mejoraron los diagnósticos de compatibilidad y las guías multilingües para las aplicaciones con runtimes JavaFX incorporados.

6.0.0 2026-07-20

Protector4J 6.0 es una versión principal basada en una arquitectura de protección completamente rediseñada, no una actualización incremental habitual de la serie 5.x.

Arquitectura y protección

• Se rediseñó la arquitectura fundamental de Protector4J y se introdujo el nuevo motor de protección P4JX.
• Se añadieron cerca de 100 medidas de protección en la generación de archivos, la carga de clases, la ejecución, la protección contra depuración y la integridad de los artefactos.
• Se elevó considerablemente la barrera frente a la ingeniería inversa. La nueva arquitectura está diseñada para dificultar enormemente el descifrado a corto plazo, incluso con herramientas avanzadas de análisis asistido por IA.
• Se reforzaron las solicitudes de licencia, las descargas de runtimes, la verificación de artefactos y la seguridad de los instaladores multiplataforma.

Experiencia del producto

• Se incorporó compatibilidad con JDK 8, 11, 17, 21 y 25, con flujos gráficos de empaquetado para aplicaciones Java, JavaFX, Spring Boot y Tomcat.
• Se añadieron el análisis de compatibilidad, el cifrado selectivo de clases, la protección de JAR de dependencias, la importación/exportación de tareas YAML y las compilaciones por lotes para varias plataformas de destino.
• Se rediseñó la interfaz de escritorio, que ahora admite 11 idiomas y guarda la preferencia de idioma.

Notas de migración

Protector4J 6.0 presenta diferencias importantes de uso respecto a las versiones anteriores. Antes de utilizarlo, vuelva a consultar la documentación más reciente y vuelva a compilar y migrar sus aplicaciones cifradas a la versión 6.0 tan pronto como sea posible para beneficiarse de una protección más sólida.

Descargar Protector4J 6.0

Versiones anteriores