변경 이력

6.0.19 2026-08-15

계정 없이 암호화할 때 체험판 라이선스 안내를 명확화

계정 자격 증명이 제공되지 않은 경우, CLI 경고는 이제 보호된 애플리케이션이 체험판 라이선스로 동작하며 7일 동안만 실행된다는 점을 분명히 알리고, 라이선스 구매처로 https://protector4j.com 을 안내합니다. 이전 경고는 "체험판 라이선스"라고만 언급할 뿐, 그것이 애플리케이션에 어떤 의미인지 설명하지 않았습니다.
GUI는 암호화를 시작하기 전에 같은 내용을 대화 상자로 표시하며 "구매", "작업 계속", "작업 취소" 세 가지 선택지를 제공합니다. 구매 버튼은 현재 선택된 서버 리전에 해당하는 구매 페이지를 열기 때문에, .cn 리전을 선택한 사용자가 .com 사이트로 이동되지 않습니다.

외부 도구에서 GUI를 실행하기 위한 시작 인수

GUI가 시작 인수 p4j-ui [--task-file <file>] [<input-file>] 를 받도록 되었습니다. 작업 파일을 전달하면 일반 가져오기 절차를 거쳐 최종 확인 페이지로 바로 이동합니다. 일반 입력 경로를 전달하면 새 작업에 미리 채워지며, .war 는 자동으로 Tomcat 흐름을 선택하고 .jar 는 애플리케이션 유형 선택 페이지에서 멈춥니다. JAR는 Java 애플리케이션, Spring Boot 애플리케이션 또는 라이브러리일 수 있기 때문입니다. 이는 IDE 플러그인 같은 외부 도구를 위한 연동 인터페이스이며, 알 수 없는 하이픈 인수는 무시되므로 인수 없이 GUI를 실행할 때의 동작은 이전과 완전히 동일합니다.

단독 라이브러리 암호화를 개발 중으로 표시

단독 라이브러리 암호화는 6.x 라인에서 아직 사용할 수 없으므로 이제 명확하게 표시됩니다. GUI의 해당 카드는 회색으로 비활성화되고 "개발 중" 배지가 붙으며, CLI의 encode 명령은 작업을 시작하는 대신 설명 메시지를 출력하고 종료합니다. 이 기능은 이후 릴리스에서 제공될 예정입니다.

6.0.18 2026-08-13

Spring Boot p4jx-fat 레이아웃의 멀티 릴리스 JAR 지원

Spring Boot p4jx-fat 레이아웃에서 멀티 릴리스 의존성이 항상 기본 버전으로 로드되던 문제를 수정했습니다. 중첩된 BOOT-INF/lib JAR을 풀 때 클래스 로더가 항목을 문자 그대로의 이름으로 저장했기 때문에 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

비 ASCII 문자가 포함된 Windows 경로에서 보호된 애플리케이션이 시작되지 않던 문제 수정

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 명령은 링크를 만들지 못한 것을 경고로 처리하지만 종료 코드는 0이 아닌 값을 반환하므로, 인코더가 이를 완전한 실패로 판단하고 이미 해제한 런타임을 삭제했습니다. 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 비즈니스 로직, JspC로 미리 컴파일된 JSP 서블릿 클래스에서 엔드투엔드로 검증했습니다. CLI 플래그는 --encrypt-strings none|constant|inline이며 GUI에서도 동일한 선택을 제공합니다.
재작성할 수 없는 메서드(오래된 클래스 파일 형식의 인터페이스, 64 KB 한도에 가까운 메서드, 드문 직렬화 경계 사례)는 표준 V72 계층으로 폴백하므로 결과가 이전보다 약해지지 않습니다.

Spring Boot p4jx-fat 시작 속도 향상

순수 fat 레이아웃의 Spring Boot 클래스 로더가 중첩 리소스 인덱스를 미리 모두 읽는 대신 필요할 때 읽어, 대규모 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`을 사용하는 보호된 애플리케이션의 시작 오류 수정

프레임워크가 javax.lang.model API를 참조하는 보호된 애플리케이션에서 시작 시 NoClassDefFoundError: javax/lang/model/SourceVersion이 발생하는 문제를 수정했습니다. 대표적인 예가 Spring Data JPA로, 그 리포지토리 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에서 일곱 개 플랫폼을 지원합니다. 런타임은 선택한 버전에 대해 SHA-256이 등록된 공식 IPC 라이브러리에만 스레드 attach 권한을 부여하고, 실제로 스레드가 attach할 때 호출 모듈을 다시 검증합니다. 경로, 해시, 라이브러리 이름은 명령줄에서 받지 않습니다. macOS 26에서는 JxBrowser 9.0.1 이상을 사용하십시오. TeamDev가 해당 릴리스에서 Engine 생성 시 발생하는 Chromium 크래시를 수정했으며, 9.0.0은 일반 JDK에서도 동일하게 크래시가 발생합니다.
보호된 애플리케이션이 NullPointerException을 던질 때 발생하던 ClassFormatError를 수정했습니다. 6.0.9의 수정은 JVM의 상세 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비트 정수로 저장하므로, 점으로 구분된 1~4개의 숫자는 각각 0에서 65535 사이여야 합니다. 필드를 비워 두면 이전과 같이 0.0.0.0이 됩니다.

6.0.11 2026-07-27

보호된 애플리케이션용 네이티브 Windows 런처

Java App 패키지, 세 가지 Spring Boot 레이아웃, Tomcat 패키지에서 네이티브 Windows EXE를 선택적으로 생성할 수 있습니다. Windows x64, x86, ARM64용 콘솔 및 GUI 런처를 제공하며 기존 실행 스크립트도 모든 패키지에 그대로 유지됩니다.
EXE 파일 이름, 모드, 아이콘, Windows 버전 메타데이터를 지정하는 CLI 및 GUI 설정을 추가했습니다. 다중 플랫폼 작업은 선택한 Windows 대상에만 EXE를 생성하며, 설정은 버전 2의 p4j-task.yml에 보존됩니다. 버전 1 작업 파일도 계속 읽을 수 있습니다.
순수 Win32 런처인 JExeKit을 패키지의 vlxjre, 정확한 클래스 경로 및 JVM 인수와 통합했습니다. Java를 시작하기 전에 패키지 외부로 벗어나는 경로, 재분석 지점 치환, 안전하지 않은 에이전트 또는 부트 클래스 경로 옵션을 거부합니다.
JExeKit 템플릿은 AES-GCM으로 암호화된 .jxt 리소스로만 포함되며 생성할 때 메모리에서만 복호화됩니다. 생성된 각 런처의 매개변수 블록에는 production 상태의 Ed25519 서명이 포함되며, 아이콘·버전·매니페스트·매개변수 변경은 사용자가 마지막으로 적용하는 Authenticode 서명 전에 모두 완료됩니다.

6.0.10 2026-07-27

WAR 구조를 유지하는 더 빠른 Tomcat 의존성 로딩

클래스를 로드할 때마다 보호된 WEB-INF/lib 중첩 JAR 전체를 다시 읽고 해시를 계산하여 Tomcat 시작이 크게 느려지는 문제를 수정했습니다. VLX 1.0.17은 이제 밀봉된 각 중첩 JAR을 한 번만 검증하고 인증된 출처 정보를 VM 내부에 캐시하며, 요청된 각 클래스는 암호화된 클래스 인덱스와 계속 대조합니다.
임시 web-libs 압축 해제 및 마운트 우회 방식을 제거했습니다. WEB-INF/lib/*.jar는 보호된 .p4jx 아카이브 안에 그대로 유지되어 원래 WAR 구조와 애플리케이션 격리를 보존합니다. JDK 11, 17, 21, 25용 VLX 1.0.17 런타임을 지원되는 24개 플랫폼 조합에 게시했습니다. JDK 8은 기존 ZIP overlay 경로를 유지하며 VLX 1.0.11을 계속 사용합니다.
애플리케이션 module-info.class의 호환성 스캔을 수정했습니다. 모듈 설명자에는 메서드 본문이 없으므로 이제 암호화 대상에서 자동으로 제외되며, 설명자 도구에서는 계속 읽을 수 있습니다.
GUI가 내보낸 CLI 명령에서 --java-version, --target-platform, --create-new-folder를 패키저 인수 뒤에 연속된 접미 옵션으로 배치할 수 있습니다. 기존 접두 형식도 계속 지원됩니다.

6.0.9 2026-07-25

암호화된 앱이 NullPointerException을 출력할 때의 크래시 수정

보호된 메서드가 암시적 NullPointerException을 던지고 애플리케이션이 해당 메시지를 읽거나 스택 트레이스를 출력할 때 발생할 수 있던 JVM 크래시를 수정했습니다. 런타임의 "도움이 되는 NPE 상세 정보" 기능이 메서드의 암호화된 바이트코드에서 "because ... is null" 텍스트를 복원하려다 잘못된 메모리를 참조하여 VM이 크래시되었습니다(JavaFX FXML 애플리케이션에서 확인됨). 이제 보호된 메서드에서는 상세 메시지를 건너뛰고 표준 NullPointerException으로 대체합니다. 예외 유형, 스택 트레이스, 애플리케이션이 제공한 메시지에는 영향을 주지 않습니다.
JDK 17, 21, 25 런타임을 이 수정과 함께 VLX 1.0.16으로 다시 빌드했습니다. "도움이 되는 NPE 상세 정보" 기능은 JDK 14 이전에는 존재하지 않으므로 JDK 11은 영향을 받지 않고 VLX 1.0.15를 유지합니다. JDK 8은 VLX 1.0.11을 유지합니다.

6.0.8 2026-07-24

필요할 때 다운로드하는 Tomcat 런타임과 프로덕션 안전 기본값

app.p4jx 내부의 Tomcat 클래스가 더 이상 물리적 클래스패스 JAR로 보이지 않아 배포된 자체 보호 인코더가 Tomcat WAR를 패키징하지 못하던 문제를 수정했습니다. Tomcat 9.0.107과 10.1.53은 이제 Servlet 네임스페이스에 따라 선택되는 변경 불가능한 버전 지정 R2/COS 아티팩트입니다. 처음 사용할 때 다운로드하여 로컬에 캐시하고 정확한 SHA-256과 JAR 목록을 검증합니다. 변조된 캐시는 폐기한 뒤 다시 다운로드합니다.
공개 WEB-INF/lib JAR는 이제 애플리케이션별로 격리되고 해시에 바인딩된 물리적 Web 리소스로 배치되어, 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는 이제 중첩 JAR와 클래스의 정확한 SHA-256 메타데이터를 app.p4jx에 봉인하며, 알 수 없거나 교체되거나 변조된 종속성은 계속 거부됩니다.
JDK 11의 MethodHandles.Lookup#defineClass가 JDK 11 전용 소스 마커를 사용하여 발생하던 Spring CGLIB 및 Hibernate Byte Buddy 실패를 수정했습니다. 동적 신뢰에는 여전히 VM이 검증한 호출 클래스 또는 로더 출처가 필요하며, 마커 문자열, 클래스 이름, 경로, 패키지명 및 CodeSource는 신뢰를 부여하지 않습니다.
JDK 11, 17, 21, 25용 VLX 1.0.15 런타임을 지원되는 24개 플랫폼 조합에 배포했습니다. 실제 FXML, Swing/AWT, Tomcat 중첩 종속성 로드, 출처 및 변조 부정 사례를 포함한 엄격한 L1-L5 게이트를 모두 통과했습니다. JDK 8은 VLX 1.0.11을 유지합니다.

6.0.6 2026-07-22

신뢰된 클래스 정의 출처 전파

보호된 JavaFX FXML 애플리케이션의 시작 실패를 수정했습니다. MethodUtil은 VM이 출처를 검증한 Trampoline 헬퍼를 defineClass(byte[])로 정의합니다. 신뢰는 이제 클래스 이름, 경로, 패키지명, CodeSource 문자열이 아니라 VM이 검증한 클래스 또는 로더 출처에서만 전파됩니다.
fx:controller, 속성 요소, Controller 주입, WebView 시작을 포함하는 실제 FXML 커버리지를 추가했으며, 신뢰된 동적 정의, 2단계 전파, 알 수 없는 출처, 승인되지 않은 JAR, protected class 이름 교체에 대한 회귀 테스트도 추가했습니다.
JDK 11, 17, 21, 25용 VLX 1.0.14 런타임을 배포했습니다. JDK 8은 VLX 1.0.11을 유지합니다.

6.0.5 2026-07-21

JavaFX 네이티브 런타임 무결성

패키지화된 JavaFX DLL을 vlxjre/bin에 배치하고 런처의 네이티브 라이브러리 검색 경로를 조정하여 Windows에서 발생하던 JavaFX WebView 시작 실패(Graphics Device initialization failed / No toolkit found)를 해결했습니다.
암호화된 app.p4jx 허용 목록을 외부 네이티브 라이브러리까지 확장했습니다. JavaFX 네이티브 파일은 경로와 관계없이 정확한 SHA-256 값과 일치해야 하며, Glass가 실제로 로드된 파일을 다시 검증합니다. 인식되지 않거나 변조된 파일은 거부됩니다.
JDK 11, 17, 21, 25용으로 업데이트된 Protector4J 런타임을 배포했습니다. 지원되는 JavaFX 플랫폼 조합은 L5.1-L5.4를 통과했으며, WebView 시작과 모듈 JAR, jdk.jsobject, Glass 네이티브 라이브러리의 변조 거부를 검증했습니다.

6.0.4 2026-07-21

외부 모듈 무결성 및 JavaFX 런타임 호환성

외부 모듈에 대한 경로 기반 신뢰 방식을 제거했습니다. 이제 모든 외부 모듈 JAR은 app.p4jx에 내장된 정확한 SHA-256 허용 목록 항목과 일치해야 하며, 위치와 관계없이 인식되지 않거나 변조된 파일은 거부됩니다.
JavaFX module-info.class를 통한 종속성 폐쇄 자동 감지와 javafx.media 및 jdk.jsobject를 포함한 고정된 JavaFX / JDK 모듈의 제어된 허용 기능을 추가했습니다.
새롭게 출시된 P4JX 런타임을 통해 지원되는 JDK 버전 및 플랫폼 전반에서 JavaFX WebView 시작 문제와 부트 레이어 구성 후의 E818 / ClassFormatError 오류를 수정했습니다.

6.0.3 2026-07-20

JavaFX WebView 모듈 호환성

동일한 JDK/VLX 버전으로 다시 빌드된 지원 P4JX 런타임에서 선택적 jdk.jsobject 모듈을 확인하지 못하던 문제를 수정했습니다. 이제 전체 lib/modules 이미지의 바이트가 다르다는 이유만으로 호환 런타임을 거부하지 않습니다.
JDK 계열 및 플랫폼별 아티팩트 선택, 정확한 모듈 SHA-256 및 모듈 이름 검증, 설치 후 의존성 폐쇄 재검증은 그대로 유지됩니다.

6.0.2 2026-07-20

JavaFX WebView 호환성

javafx.media를 javafx.web과 함께 패키징하고, 축소된 런타임에 모듈이 없을 때 P4JX와 정확히 일치하는 jdk.jsobject를 자동으로 확인하여 JavaFX WebView 시작 실패를 수정했습니다.
SHA-256으로 고정되고 버전, 플랫폼, 런타임에 연결된 선택적 모듈을 지역별 공개 다운로드 서비스에서 가져오는 기능을 추가했습니다. 모듈이 이미 포함된 런타임은 다운로드를 건너뜁니다.

6.0.1 2026-07-20

JavaFX 호환성

JavaFX 런타임 클래스가 포함된 fat JAR의 시작 실패 문제를 수정했습니다. 호환성 규칙 자동 적용은 이제 포함된 JavaFX API, 구현체 및 JNI 브리지 네임스페이스를 암호화하지 않고 유지하여 패키지에 포함된 JavaFX 모듈과의 클래스 소유권 중복을 방지합니다.
JavaFX 런타임을 셰이딩한 애플리케이션의 호환성 진단 및 다국어 안내를 개선했습니다.

6.0.0 2026-07-20

Protector4J 6.0은 5.x 시리즈의 일반적인 점진적 업데이트가 아니라 보호 아키텍처를 전면 재설계한 메이저 릴리스입니다.

아키텍처 및 보호

Protector4J의 기반 아키텍처를 재설계하고 새로운 P4JX 보호 엔진을 도입했습니다.
아카이브 생성, 클래스 로딩, 런타임 실행, 디버깅 방지, 아티팩트 무결성 등 각 계층에 약 100개의 보호 조치를 추가했습니다.
리버스 엔지니어링의 장벽을 크게 높였습니다. 새로운 아키텍처는 고급 AI 지원 분석 도구를 사용하더라도 단기간 내 크래킹을 매우 어렵게 만드는 것을 목표로 설계되었습니다.
라이선스 요청, 런타임 다운로드, 아티팩트 검증, 크로스 플랫폼 설치 프로그램의 보안을 강화했습니다.

제품 경험

JDK 8, 11, 17, 21, 25를 지원하며 Java, JavaFX, Spring Boot, Tomcat 애플리케이션을 위한 그래픽 패키징 워크플로를 제공합니다.
호환성 검사, 선택적 클래스 암호화, 종속 JAR 보호, YAML 작업 가져오기/내보내기, 여러 대상 플랫폼의 일괄 빌드를 추가했습니다.
데스크톱 인터페이스를 재설계하고 11개 언어 및 영구 언어 설정을 지원합니다.