История изменений

6.0.19 2026-08-15

Более понятное предупреждение о пробной лицензии при шифровании без учётной записи

• Если учётные данные не указаны, предупреждение CLI теперь прямо сообщает, что защищённое приложение будет использовать пробную лицензию и проработает только 7 дней, и указывает https://protector4j.com для покупки лицензии. Раньше предупреждение упоминало лишь «пробную лицензию», не поясняя, что это означает для приложения.
• Графический интерфейс показывает то же предупреждение в диалоговом окне перед началом шифрования с тремя вариантами: «Купить», «Продолжить задачу» и «Отменить задачу». Кнопка покупки открывает страницу покупки выбранного региона сервера, поэтому пользователи региона .cn не попадают на сайт .com.

Аргументы запуска для открытия графического интерфейса из других инструментов

• Графический интерфейс теперь принимает аргументы запуска: p4j-ui [--task-file <file>] [<input-file>]. Файл задачи проходит обычный поток импорта прямо до страницы финального подтверждения. Обычный путь к входному файлу предварительно заполняется в новой задаче: .war автоматически выбирает поток Tomcat, а .jar останавливается на странице выбора типа приложения, потому что JAR может быть Java-приложением, приложением Spring Boot или библиотекой. Это интерфейс интеграции для внешних инструментов, например плагинов IDE; неизвестные аргументы с дефисом игнорируются, поэтому запуск графического интерфейса без аргументов ведёт себя ровно так же, как раньше.

Отдельное шифрование библиотек помечено как находящееся в разработке

• Отдельное шифрование библиотек пока недоступно в линии 6.x, и теперь это указано явно: соответствующая карточка в графическом интерфейсе затенена и помечена значком «В разработке», а команда CLI encode завершается с пояснительным сообщением вместо запуска задачи. Эта функция появится в одном из будущих выпусков.

6.0.18 2026-08-13

Поддержка многоверсионных JAR в компоновке Spring Boot p4jx-fat

• Исправлена ошибка, из-за которой в компоновке Spring Boot p4jx-fat многоверсионные зависимости всегда загружались из базовой версии. При распаковке вложенного JAR из BOOT-INF/lib загрузчик классов сохранял записи под их буквальными именами, поэтому классы из META-INF/versions/ никогда не выбирались и всегда срабатывал откат на базовую версию. Конкретное проявление: со Spring Framework 7.0.5 класс VirtualThreadDelegate разрешался в заглушку базовой версии, которая безусловно выбрасывает UnsupportedOperationException, поэтому приложение на JDK 25 с параметром spring.threads.virtual.enabled=true не запускалось. Многие широко используемые зависимости поставляются как многоверсионные JAR, поэтому другие версионно-зависимые ветки кода страдали так же.
• Теперь загрузчик классов разрешает многоверсионные записи во время загрузки, выбирая наибольшую версию, поддерживаемую запущенным JDK, а упаковщик применяет то же правило при построении индекса ресурсов fat, поэтому индекс и загрузчик всегда согласованы в том, какая запись побеждает. Две другие компоновки, fat и separate, никогда не были затронуты: они оставляют зависимости обычными JAR-файлами, которые открывает сама JVM.

6.0.17 2026-08-13

Исправлен запуск защищённых приложений по путям Windows с не-ASCII символами

• Исправлена ошибка, из-за которой защищённые приложения не запускались в Windows, если их путь содержал не-ASCII символы, например китайские иероглифы. В зависимости от того, в каком месте путь читался неверно, запуск завершался либо ошибкой архива E816, либо сбоем расшифровки, проявлявшимся как ClassFormatError. Среда выполнения открывала архив и нормализовала пути побайтно, поэтому символ из устаревшей кодовой страницы, второй байт которого оказывается равен 0x5C — обратной косой черте, — разрывался посередине, а его хвост читался как разделитель каталогов. В GBK так закодированы многие повседневные китайские иероглифы. Пути, состоящие только из ASCII-символов, никогда не были затронуты.
• В Windows среда выполнения теперь преобразует пути в широкие символы через системную кодовую страницу ANSI перед открытием файлов и перед вычислением отпечатка среды выполнения — именно так штатный JDK всегда открывал файлы. Изменена только ветка кода для Windows; поведение в Linux и macOS осталось прежним. Все пять линеек JDK пересобраны с этим исправлением: JDK 25, 21 и 17 до VLX 1.0.22, JDK 11 до VLX 1.0.20 и JDK 8 до VLX 1.0.13.

6.0.16 2026-08-10

Исправлена сборка пакетов в Windows для целевых платформ Linux и macOS

• Исправлена ошибка сборки пакета в Windows, когда целевой платформой является Linux или macOS. При распаковке входящей в комплект среды выполнения выводилось сообщение Failed to extract P4JX runtime, хотя фактически среда распаковывалась правильно. В Windows создание символических ссылок требует повышения прав, а среды выполнения для Linux и macOS содержат чуть более сотни таких ссылок в каталоге legal/ — это тексты лицензий, которые jlink делает ссылками на java.base, чтобы не дублировать их. Входящая в состав Windows команда tar считает это предупреждением, но всё равно возвращает ненулевой код выхода, который кодировщик воспринимал как полный сбой и затем удалял уже распакованную среду. Сборка в Windows для целевой платформы Windows никогда не была затронута, поскольку в средах выполнения для Windows символических ссылок нет вовсе.
• Работа с архивами больше не зависит от команды tar конкретной платформы. Кодировщик теперь сам читает и распаковывает среды выполнения .tar.gz и материалы JavaFX, поэтому поведение в Windows, Linux и macOS полностью совпадает. Права доступа к файлам, включая бит выполнения у программы запуска, берутся из самого архива, а не из файловой системы хоста. В Windows символические ссылки на лицензии пропускаются: во время работы приложения они не выполняют никаких функций и не входят в отпечаток среды выполнения, поэтому приложения, защищённые в Windows, расшифровываются точно так же, как раньше.

6.0.15 2026-08-08

Исправления диалога обновления

• Диалог «Новая версия» теперь открывается фиксированного разумного размера, а не растягивается на весь экран при длинном списке изменений.
• В панель инструментов добавлен пункт «Проверить обновления», позволяющий проверить наличие новой версии в любой момент, а не только при запуске.

6.0.14 2026-08-07

Встроенное шифрование строковых констант, теперь по умолчанию

• Добавлен режим встроенной защиты строк, который переписывает инструкции загрузки строк ldc в вызов синтетического метода расшифровки, отдельного для каждого класса, полностью удаляя открытый текст строковой константы из пула констант. Открытый текст больше не попадает в SymbolTable при загрузке класса, появляется в куче только тогда, когда этот код действительно выполняется, а неиспользуемые строки остаются зашифрованными. Шифртекст хранится внутри тела класса и защищён существующим пометодным шифрованием. Это чисто кодировщицкое преобразование байт-кода: формат архива и среда выполнения не меняются, и это работает на каждой поддерживаемой линии JDK без обновления среды выполнения.
• Защита строк теперь представляет собой единый параметр с тремя режимами — Нет, Стандартный (пул констант V72) и Встроенный — и Встроенный является значением по умолчанию для всех типов приложений, включая Tomcat. Он проверен сквозным образом на обычных сервлетах, бизнес-логике со switch по строкам и классах сервлетов JSP, предварительно скомпилированных JspC. Флаг CLI — --encrypt-strings none|constant|inline, и графический интерфейс предлагает тот же выбор.
• Метод, который нельзя переписать — интерфейс в старом формате файла класса, метод вблизи предела 64 КБ или редкий пограничный случай сериализации — откатывается к стандартному слою V72, поэтому результат никогда не слабее прежнего.

Более быстрый запуск Spring Boot p4jx-fat

• Загрузчик классов Spring Boot в режиме pure-fat теперь читает индекс вложенных ресурсов по требованию, а не заранее, сокращая работу при запуске крупных приложений p4jx-fat.

Учётные данные аккаунта из переменных окружения

• Команды encode, javaapp, springboot и tomcat, а также режим файла задач теперь могут читать электронную почту и пароль аккаунта из P4JX_ACCOUNT_EMAIL и P4JX_ACCOUNT_PASSWORD (или P4JX_ACCOUNT_PASSWORD_MD5); они используются только при отсутствии соответствующего параметра командной строки, поэтому экспортированный файл задач остаётся без учётных данных.

6.0.13 2026-08-05

Исправление запуска защищённых приложений, использующих javax.lang.model

• Исправлена ошибка NoClassDefFoundError: javax/lang/model/SourceVersion при запуске защищённых приложений, фреймворки которых обращаются к API javax.lang.model — прежде всего Spring Data JPA, чей repository AOT processor использует SourceVersion во время инициализации контейнера. Модуль java.compiler, ранее удалённый из поставляемой среды выполнения, снова включён. Это модуль, содержащий только API, без реализации компилятора, поэтому ToolProvider.getSystemJavaCompiler() по-прежнему возвращает null, а jdk.compiler по-прежнему отсутствует — поверхность защиты не меняется.
• Среды выполнения JDK 17, 21 и 25 пересобраны до VLX 1.0.21, а JDK 11 — до VLX 1.0.19, все с восстановленным модулем java.compiler. JDK 8 не затронут, так как не имеет системы модулей и уже предоставляет эти классы.

6.0.12 2026-08-02

Поддержка JxBrowser 9 и исправление сбоя в защищённых приложениях, выбрасывающих NullPointerException

• Защищённые приложения теперь могут встраивать JxBrowser 9. --native-compat jxbrowser выбирает одну из девяти версий встроенного каталога, с 9.0.0 по 9.3.1, на семи платформах для Java 17, 21 и 25. Среда выполнения предоставляет право присоединения потока только официальной библиотеке IPC, SHA-256 которой зарегистрирован для выбранной версии, и повторно проверяет вызывающий модуль в момент фактического присоединения потока. Пути, хеши и имена библиотек никогда не принимаются из командной строки. В macOS 26 используйте JxBrowser 9.0.1 или новее: в этом выпуске TeamDev исправила сбой Chromium при создании Engine, а 9.0.0 аварийно завершается там и на обычном JDK.
• Исправлена ошибка ClassFormatError в защищённых приложениях, выбрасывающих NullPointerException. Исправление из 6.0.9 подавляло подробное сообщение NPE виртуальной машины отдельно для каждого метода, чего оказалось недостаточно: эта функция разбирает тела методов как стандартный байт-код, и после преобразования их средствами P4JX никакой признак на уровне метода не может подтвердить, что такой разбор остаётся корректным. Теперь среда выполнения отключает подробное сообщение безусловно. Тип исключения, трассировка стека и сообщение, заданное приложением, не изменяются. Среды выполнения для JDK 17, 21 и 25 пересобраны как VLX 1.0.20; JDK 11 не затронут и остаётся на VLX 1.0.18, JDK 8 остаётся на VLX 1.0.12.
• java -version теперь сообщает сборку среды выполнения VLX, поэтому входящую в комплект среду можно определить без распаковки.
• Два поля версии для Windows EXE теперь проверяются до начала упаковки, а не приводят к сбою в середине процесса. Windows хранит каждый компонент как беззнаковое 16-битное целое, поэтому каждое из одного-четырёх чисел, разделённых точками, должно находиться в диапазоне от 0 до 65535. Пустые поля по-прежнему означают 0.0.0.0.

6.0.11 2026-07-27

Нативные средства запуска Windows для защищённых приложений

• Добавлено необязательное создание нативных EXE-файлов Windows для пакетов Java App, всех трёх компоновок Spring Boot и пакетов Tomcat. Консольные и графические средства запуска доступны для Windows x64, x86 и ARM64, а существующие сценарии запуска сохраняются в каждом пакете.
• В CLI и графическом интерфейсе добавлены настройки имени EXE-файла, режима, значка и метаданных версии Windows. В многоплатформенных заданиях EXE создаётся только для выбранных целей Windows, а настройки сохраняются в версии 2 файла p4j-task.yml; файлы заданий версии 1 по-прежнему читаются.
• Чистый Win32-лаунчер JExeKit интегрирован с включённой в пакет vlxjre, точным classpath и аргументами JVM. Перед запуском Java он отклоняет пути с выходом за пределы пакета, подмены через точки повторной обработки и небезопасные параметры агентов или загрузочного classpath.
• Шаблоны JExeKit встраиваются только как зашифрованные AES-GCM ресурсы .jxt и расшифровываются в памяти при создании. Каждый созданный лаунчер содержит Ed25519-подпись со статусом production для блока параметров; изменения значка, версии, манифеста и параметров завершаются до окончательной пользовательской подписи Authenticode.

6.0.10 2026-07-27

Ускоренная загрузка зависимостей Tomcat с сохранением структуры WAR

• Исправлено значительное замедление запуска Tomcat, вызванное тем, что при загрузке каждого класса целиком повторно считывался и хешировался защищённый вложенный JAR из WEB-INF/lib. VLX 1.0.17 теперь проверяет каждый запечатанный вложенный JAR только один раз, кэширует его подтверждённое происхождение внутри VM и продолжает сверять каждый запрошенный класс с зашифрованным индексом классов.
• Удалён временный обходной путь с распаковкой и подключением web-libs. Файлы WEB-INF/lib/*.jar остаются внутри защищённого архива .p4jx, сохраняя исходную структуру WAR и изоляцию приложений. Среды выполнения VLX 1.0.17 для JDK 11, 17, 21 и 25 опубликованы для 24 поддерживаемых комбинаций платформ. JDK 8 сохраняет существующий путь ZIP overlay и остаётся на VLX 1.0.11.
• Исправлена проверка совместимости файла приложения module-info.class. Дескрипторы модулей не содержат тел методов, поэтому теперь автоматически исключаются из шифрования и при этом остаются доступными для чтения инструментами работы с дескрипторами.
• В командах CLI, экспортируемых графическим интерфейсом, параметры --java-version, --target-platform и --create-new-folder теперь можно указывать после аргументов упаковщика в виде непрерывного суффикса. Существующая префиксная форма по-прежнему поддерживается.

6.0.9 2026-07-25

Исправление сбоя для зашифрованных приложений, выводящих NullPointerException

• Исправлен сбой JVM, который мог происходить, когда защищённый метод выбрасывал неявное NullPointerException, а приложение читало его сообщение или выводило трассировку стека. Функция «полезных сведений об NPE» среды выполнения пыталась восстановить текст "because ... is null" из зашифрованного байт-кода метода, обращалась к недопустимой памяти и приводила к сбою VM (наблюдалось в приложениях JavaFX FXML). Защищённые методы теперь пропускают подробное сообщение и возвращают стандартное NullPointerException; тип исключения, трассировка стека и любое сообщение, заданное приложением, не затрагиваются.
• Среды выполнения для JDK 17, 21 и 25 пересобраны до VLX 1.0.16 с этим исправлением. JDK 11 не затронут, так как функция полезных сведений об NPE отсутствует до JDK 14, и остаётся на VLX 1.0.15; JDK 8 остаётся на VLX 1.0.11.

6.0.8 2026-07-24

Загружаемые по требованию среды Tomcat и безопасные настройки по умолчанию для рабочей среды

• Исправлена ошибка, из-за которой опубликованный самозащищённый кодировщик не мог упаковывать Tomcat WAR: классы Tomcat внутри app.p4jx больше не были видны как физический JAR в пути классов. Tomcat 9.0.107 и 10.1.53 теперь поставляются как неизменяемые версионированные артефакты R2/COS, выбираются по пространству имён Servlet, загружаются при первом использовании, сохраняются в локальном кэше и проверяются по точному SHA-256 и списку JAR. Изменённый кэш удаляется и загружается заново.
• Публичные JAR из WEB-INF/lib теперь размещаются как отдельные для каждого приложения физические веб-ресурсы, привязанные по хэшу. Это устраняет повторное чтение и проверку вложенного архива для каждого класса при запуске Spring.
• Новые сборки теперь по умолчанию используют рабочую конечную точку лицензирования https://protector4j.com. Внутренняя конечная точка http://10.10.10.16:16002 используется только при явном выборе P4JX_LICENSE_MODE=dev или -PlicenseMode=dev.

6.0.7 2026-07-24

Вложенные зависимости Tomcat и доверенные динамические классы

• Исправлены сбои защищённых Tomcat WAR при загрузке классов или сервисов из WEB-INF/lib/*.jar. Теперь Protector4J запечатывает в app.p4jx точные метаданные SHA-256 вложенных JAR и классов; неизвестные, подменённые или изменённые зависимости по-прежнему отклоняются.
• Исправлены сбои Spring CGLIB и Hibernate Byte Buddy в JDK 11, вызванные тем, что MethodHandles.Lookup#defineClass использует специальный для JDK 11 маркер источника. Динамическое доверие по-прежнему требует проверенного VM происхождения вызывающего класса или загрузчика; строки маркеров, имена классов, пути, пакеты и CodeSource не предоставляют доверия.
• Опубликованы среды выполнения VLX 1.0.15 для JDK 11, 17, 21 и 25 в 24 поддерживаемых платформенных комбинациях. Все они прошли строгие проверки L1-L5, включая реальный FXML, Swing/AWT, загрузку вложенных зависимостей Tomcat, а также негативные сценарии происхождения и изменения. JDK 8 остаётся на VLX 1.0.11.

6.0.6 2026-07-22

Надёжное происхождение определения классов

• Исправлены сбои запуска защищённых JavaFX FXML-приложений: MethodUtil определяет вспомогательный класс Trampoline, происхождение которого проверено VM, через defineClass(byte[]). Доверие теперь передаётся только от проверенного VM происхождения класса или загрузчика, а не от имён классов, путей, пакетов или строк CodeSource.
• Добавлено реальное покрытие FXML с fx:controller, элементами свойств, внедрением Controller и запуском WebView, а также регрессионные проверки для доверенных динамических определений, двухуровневой передачи, неизвестных источников, неразрешённых JAR и подмены имён protected class.
• Опубликованы среды выполнения VLX 1.0.14 для JDK 11, 17, 21 и 25. JDK 8 остаётся на VLX 1.0.11.

6.0.5 2026-07-21

Целостность нативной среды выполнения JavaFX

• Устранены сбои запуска JavaFX WebView в Windows (Graphics Device initialization failed / No toolkit found): упакованные DLL-файлы JavaFX размещены в vlxjre/bin, а поиск нативных библиотек в средстве запуска приведён в соответствие.
• Зашифрованный список разрешений в app.p4jx расширен на внешние нативные библиотеки. Файлы JavaFX должны соответствовать точным значениям SHA-256 независимо от пути, а Glass повторно проверяет фактически загруженный файл; неизвестные или изменённые файлы отклоняются.
• Опубликованы обновлённые среды выполнения Protector4J для JDK 11, 17, 21 и 25. Поддерживаемые платформенные комбинации JavaFX прошли L5.1-L5.4, включая запуск WebView и отклонение изменённых модулей JAR, jdk.jsobject и нативных библиотек Glass.

6.0.4 2026-07-21

Целостность внешних модулей и совместимость среды выполнения JavaFX

• Устранено доверие к внешним модулям на основе пути. Теперь каждый JAR внешнего модуля должен точно соответствовать записи SHA-256 из списка разрешений, встроенного в app.p4jx; нераспознанные или изменённые файлы отклоняются независимо от их местоположения.
• Добавлены автоматическое определение замыкания зависимостей на основе JavaFX module-info.class и контролируемый допуск закреплённых модулей JavaFX и JDK, включая javafx.media и jdk.jsobject.
• В новых средах выполнения P4JX исправлены проблемы запуска JavaFX WebView и ошибки E818 / ClassFormatError после создания загрузочного слоя во всех поддерживаемых версиях JDK и на всех платформах.

6.0.3 2026-07-20

Совместимость модуля JavaFX WebView

• Исправлено разрешение необязательного модуля jdk.jsobject для поддерживаемых сред P4JX, пересобранных из той же версии JDK/VLX. Совместимая среда больше не отклоняется только из-за различий в байтах полного образа lib/modules.
• Сохранены выбор артефакта по линии JDK и платформе, точная проверка SHA-256 и имени модуля, а также повторная проверка замыкания зависимостей после установки.

6.0.2 2026-07-20

Совместимость JavaFX WebView

• Устранены сбои при запуске JavaFX WebView: javafx.media теперь поставляется вместе с javafx.web, а при отсутствии модуля в сокращённой среде выполнения автоматически выбирается jdk.jsobject, точно соответствующий P4JX.
• Добавлена загрузка необязательных модулей из регионального публичного сервиса с фиксацией SHA-256 и привязкой к версии, платформе и среде выполнения. Среды, уже содержащие модуль, пропускают загрузку.

6.0.1 2026-07-20

Совместимость с JavaFX

• Исправлены сбои при запуске fat JAR со встроенными классами среды выполнения JavaFX. Автоматическое применение правил совместимости теперь оставляет пространства имен встроенных API, реализации и моста JNI JavaFX незашифрованными, предотвращая дублирование принадлежности классов с упакованными модулями JavaFX.
• Улучшены диагностика совместимости и многоязычные рекомендации для приложений со встроенными средами выполнения JavaFX.

6.0.0 2026-07-20

Protector4J 6.0 — это крупный выпуск с полностью переработанной архитектурой защиты, а не обычное последовательное обновление линейки 5.x.

Архитектура и защита

• Переработана базовая архитектура Protector4J и представлен новый механизм защиты P4JX.
• Добавлено около 100 мер защиты на уровнях создания архивов, загрузки классов, выполнения, противодействия отладке и контроля целостности артефактов.
• Существенно повышен барьер для обратной разработки. Новая архитектура призвана сделать быстрый взлом крайне сложным даже при использовании передовых инструментов анализа с поддержкой ИИ.
• Усилена безопасность запросов лицензий, загрузки сред выполнения, проверки артефактов и кроссплатформенных установщиков.

Работа с продуктом

• Добавлена поддержка JDK 8, 11, 17, 21 и 25, а также графические процессы упаковки приложений Java, JavaFX, Spring Boot и Tomcat.
• Добавлены проверка совместимости, выборочное шифрование классов, защита JAR-файлов зависимостей, импорт и экспорт задач YAML, а также пакетная сборка для нескольких целевых платформ.
• Переработан интерфейс настольного приложения: теперь он поддерживает 11 языков и сохраняет языковые настройки.

Переход на новую версию

Использование Protector4J 6.0 заметно отличается от предыдущих версий. Перед началом работы перечитайте актуальную документацию, а затем как можно скорее пересоберите и перенесите зашифрованные приложения на версию 6.0, чтобы воспользоваться усиленной защитой.

Скачать Protector4J 6.0

Предыдущие версии