Registro de cambios

6.0.20 2026-08-22

Bloqueos aleatorios de aplicaciones protegidas en todas las líneas de JDK admitidas

• Se corrigió un defecto del entorno de ejecución incluido que podía abortar una aplicación protegida de forma aleatoria, entre unos minutos y un día después del arranque. Cuando el compilador JIT descartaba el código optimizado y reconstruía un marco del intérprete, el entorno leía el operando de una instrucción de llamada a método directamente de la memoria sin descifrarlo y usaba ese valor sin sentido como índice en la caché del grupo de constantes. El síntoma notificado era un error grave de la JVM que mencionaba parameter_size; el mismo defecto también podía corromper memoria ajena sin emitir ningún error. Las aplicaciones con rutas de código calientes muy optimizadas eran las más expuestas.
• La auditoría de esta misma clase de defecto en las cinco líneas de JDK reveló otros cinco puntos que leían o escribían metadatos protegidos sin descodificarlos antes. Dos de ellos hacían que una comprobación interna de coherencia abortara la JVM al azar, y otro era una condición de carrera durante el enlazado de clases que podía entregar un puntero de grupo de constantes no válido mientras la clase aún se estaba preparando. Todos están corregidos en los entornos de ejecución publicados con esta versión.
• La corrección reside en el entorno de ejecución incluido y no en el codificador, por lo que una aplicación protegida existente debe volver a codificarse con esta versión para incorporarla.

Las aplicaciones Spring Boot 4 no arrancaban en JDK 25 con la disposición p4jx-fat

• Se corrigió que la disposición p4jx-fat resolviera las dependencias multiversión contra la versión de Java equivocada. El empaquetador usaba la línea de ejecución seleccionada en la línea de órdenes —que vuelve a 21 cuando solo se pasa --jre-home— en lugar de la versión del entorno que realmente estaba incluyendo. Por eso, al empaquetar para un entorno JDK 25 se descartaban todas las entradas a partir de META-INF/versions/22. Con Spring Framework 7 eso eliminaba ClassFileMetadataReaderFactory, que solo existe en la variante de JDK 24, de modo que toda aplicación Spring Boot 4 fallaba al arrancar con NoClassDefFoundError. Las disposiciones fat y separate nunca se vieron afectadas, porque dejan las dependencias como archivos JAR normales que abre la propia JVM.

La orden encode vuelve a funcionar en la línea de órdenes

• La versión 6.0.19 marcó el cifrado de bibliotecas independiente como en desarrollo en la interfaz gráfica y, sin querer, bloqueó también la orden encode en la línea de órdenes. Ese bloqueo se ha eliminado y encode se comporta como antes. La interfaz gráfica conserva su distintivo «En desarrollo», así que ahí no cambia nada.

Windows ARM64 deja de ser una plataforma de destino

• Se retira la compatibilidad con windows-aarch64: ya no se ofrece en la interfaz gráfica, --target-platform windows-aarch64 se rechaza, no se genera lanzador EXE para ella y no se publica entorno de ejecución incluido. Windows en ARM ejecuta el paquete windows-x64 mediante la emulación integrada del sistema operativo. Los destinos admitidos son ahora macOS en Apple Silicon e Intel, Linux en ARM64 y x64, y Windows en x64 y x86.

6.0.19 2026-08-15

Aviso más claro de licencia de prueba al cifrar sin cuenta

• Cuando no se proporcionan credenciales de cuenta, la advertencia de la CLI ahora indica claramente que la aplicación protegida usará una licencia de prueba y solo se ejecutará durante 7 días, y remite a https://protector4j.com para comprar una licencia. Antes, la advertencia solo mencionaba «una licencia de prueba» sin explicar qué significaba eso para la aplicación.
• La interfaz gráfica muestra el mismo aviso en un diálogo antes de iniciar el cifrado, con tres opciones: Comprar, Continuar la tarea y Cancelar la tarea. El botón de compra abre la página de compra de la región de servidor seleccionada, de modo que los usuarios de la región .cn no son enviados al sitio .com.

Argumentos de inicio para abrir la interfaz gráfica desde otras herramientas

• La interfaz gráfica ahora acepta argumentos de inicio: p4j-ui [--task-file <file>] [<input-file>]. Un archivo de tarea recorre el flujo de importación habitual hasta la página de confirmación final. Una ruta de entrada normal se rellena previamente en una tarea nueva: un .war selecciona automáticamente el flujo de Tomcat, mientras que un .jar se detiene en la página de selección del tipo de aplicación, porque un JAR puede ser una aplicación Java, una aplicación Spring Boot o una biblioteca. Esta es la interfaz de integración para herramientas externas como los complementos de IDE; los argumentos con guion desconocidos se ignoran, por lo que iniciar la interfaz gráfica sin argumentos se comporta exactamente igual que antes.

Cifrado de biblioteca independiente marcado como en desarrollo

• El cifrado de biblioteca independiente aún no está disponible en la línea 6.x y ahora se indica claramente: la tarjeta correspondiente de la interfaz gráfica aparece atenuada con la insignia «En desarrollo», y el comando encode de la CLI termina con un mensaje explicativo en lugar de iniciar una tarea. La función se ofrecerá en una versión futura.

6.0.18 2026-08-13

Compatibilidad con JAR multiversión en la disposición p4jx-fat de Spring Boot

• Se corrigió un problema por el que, en la disposición p4jx-fat de Spring Boot, las dependencias multiversión se cargaban siempre desde su versión base. Al desempaquetar un JAR anidado de BOOT-INF/lib, el cargador de clases guardaba las entradas con su nombre literal, de modo que las clases situadas bajo META-INF/versions/ nunca se seleccionaban y siempre se recurría a la versión base. Un síntoma concreto: con Spring Framework 7.0.5, VirtualThreadDelegate se resolvía al stub de la versión base, que lanza incondicionalmente una UnsupportedOperationException, por lo que una aplicación ejecutada en JDK 25 con spring.threads.virtual.enabled=true no arrancaba. Muchas dependencias de uso habitual se distribuyen como JAR multiversión, así que otras rutas de código específicas de versión se veían afectadas igual.
• Ahora el cargador de clases resuelve las entradas multiversión en el momento de la carga, eligiendo la versión más alta que admita el JDK en ejecución, y el empaquetador aplica la misma resolución al construir el índice de recursos fat, de forma que el índice y el cargador siempre coinciden en qué entrada prevalece. Las otras dos disposiciones, fat y separate, nunca se vieron afectadas, porque mantienen las dependencias como archivos JAR normales que abre la propia JVM.

6.0.17 2026-08-13

Corrección del arranque de aplicaciones protegidas en rutas de Windows con caracteres no ASCII

• Se corrigió el fallo de arranque de las aplicaciones protegidas en Windows cuando su ruta contenía caracteres no ASCII, por ejemplo chinos. Según en qué punto se leyera mal la ruta, el arranque fallaba con el error de archivo E816 o con un fallo de descifrado que se manifestaba como ClassFormatError. El runtime abría el archivo y normalizaba las rutas byte a byte, de modo que un carácter codificado en una página de códigos heredada cuyo segundo byte resulta ser 0x5C —la barra invertida— se partía por la mitad y su cola se leía como separador de directorios. En GBK muchos caracteres chinos de uso cotidiano se codifican así. Las rutas formadas únicamente por caracteres ASCII nunca se vieron afectadas.
• En Windows, el runtime convierte ahora las rutas a caracteres anchos mediante la página de códigos ANSI del sistema antes de abrir los archivos y antes de calcular la huella del runtime, que es como el JDK original ha abierto siempre los archivos. Solo cambió la ruta de código de Windows; Linux y macOS se comportan igual que antes. Las cinco líneas de JDK se reconstruyeron con la corrección: JDK 25, 21 y 17 a VLX 1.0.22, JDK 11 a VLX 1.0.20 y JDK 8 a VLX 1.0.13.

6.0.16 2026-08-10

Corrección del empaquetado en Windows para destinos Linux y macOS

• Se corrigió un fallo de empaquetado en Windows cuando la plataforma de destino es Linux o macOS. Al extraer el runtime incluido se informaba Failed to extract P4JX runtime aunque el runtime se había extraído correctamente. Windows no puede crear enlaces simbólicos sin privilegios elevados, y los runtimes de Linux y macOS contienen algo más de un centenar de ellos en legal/: textos de licencia que jlink apunta a java.base en lugar de duplicarlos. El comando tar que se incluye con Windows lo trata como una advertencia, pero aun así devuelve un código de salida distinto de cero, que el codificador interpretaba como un fallo definitivo y a continuación eliminaba el runtime ya extraído. El empaquetado en Windows para un destino Windows nunca se vio afectado, porque los runtimes de Windows no contienen ningún enlace simbólico.
• El tratamiento de archivos ya no depende del comando tar de cada plataforma. El codificador ahora lee y extrae por sí mismo los runtimes .tar.gz y los recursos de JavaFX, por lo que el comportamiento es idéntico en Windows, Linux y macOS. Los permisos de archivo, incluido el bit de ejecución del lanzador, provienen del propio archivo y no del sistema de archivos anfitrión. En Windows se omiten los enlaces simbólicos de licencia: no tienen ninguna función en tiempo de ejecución ni forman parte de la huella del runtime, de modo que las aplicaciones protegidas en Windows se descifran exactamente igual que antes.

6.0.15 2026-08-08

Correcciones del diálogo de actualización

• El diálogo «Nueva versión» ahora se abre con un tamaño fijo y razonable en lugar de ocupar toda la pantalla cuando el registro de cambios es largo.
• Se añadió «Buscar actualizaciones» a la barra de herramientas, para comprobar si hay una versión más reciente en cualquier momento, no solo al iniciar.

6.0.14 2026-08-07

Cifrado en línea de constantes de cadena, ahora por defecto

• Se añadió un modo de protección de cadenas en línea que reescribe las instrucciones ldc de carga de cadena como una llamada a un método de descifrado sintético propio de cada clase, eliminando por completo del pool de constantes el texto sin cifrar de una constante de cadena. El texto sin cifrar ya no entra en la SymbolTable al cargar la clase, aparece en el heap solo cuando ese código se ejecuta realmente, y las cadenas no utilizadas permanecen cifradas. El texto cifrado viaja dentro del cuerpo de la clase y queda cubierto por el cifrado por método existente. Es una transformación de bytecode puramente del lado del codificador: el formato de archivo y el runtime no cambian y funciona en todas las líneas de JDK compatibles sin actualizar el runtime.
• La protección de cadenas es ahora una única opción con tres modos — Ninguno, Estándar (pool de constantes V72) e En línea — y En línea es el valor predeterminado para todos los tipos de aplicación, incluido Tomcat. Se validó de extremo a extremo en servlets ordinarios, lógica de negocio con switch sobre cadenas y clases de servlet JSP precompiladas por JspC. La opción de CLI es --encrypt-strings none|constant|inline, y la interfaz gráfica ofrece la misma elección.
• Un método que no se puede reescribir — una interfaz en un formato de archivo de clase antiguo, un método cercano al límite de 64 KB o un raro caso límite de serialización — recurre a la capa estándar V72, por lo que el resultado nunca es más débil que antes.

Arranque más rápido de Spring Boot p4jx-fat

• El cargador de clases de Spring Boot en pure-fat ahora lee su índice de recursos anidados bajo demanda en lugar de por adelantado, reduciendo el trabajo de arranque de las grandes aplicaciones p4jx-fat.

Credenciales de cuenta desde variables de entorno

• Los comandos encode, javaapp, springboot y tomcat y el modo de archivo de tarea ahora pueden leer el correo y la contraseña de la cuenta desde P4JX_ACCOUNT_EMAIL y P4JX_ACCOUNT_PASSWORD (o P4JX_ACCOUNT_PASSWORD_MD5), que se usan solo cuando falta la opción de línea de comandos correspondiente, de modo que un archivo de tarea exportado permanece sin credenciales.

6.0.13 2026-08-05

Corrección de arranque para aplicaciones protegidas que usan javax.lang.model

• Se corrigió NoClassDefFoundError: javax/lang/model/SourceVersion al arrancar aplicaciones protegidas cuyos frameworks hacen referencia a la API javax.lang.model, en particular Spring Data JPA, cuyo repository AOT processor accede a SourceVersion durante la inicialización del contenedor. El módulo java.compiler, que antes se había eliminado del runtime incluido, vuelve a estar presente. Es un módulo solo de API, sin implementación de compilador, por lo que ToolProvider.getSystemJavaCompiler() sigue devolviendo null y jdk.compiler sigue ausente: la superficie de protección no cambia.
• Los runtimes de JDK 17, 21 y 25 se recompilan a VLX 1.0.21, y JDK 11 a VLX 1.0.19, todos con el módulo java.compiler restaurado. JDK 8 no se ve afectado porque no tiene sistema de módulos y ya proporciona estas clases.

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