word3-3

1. Artifact: log4j:log4j:1.2.17
Original JDK Target
Java 1.4 (Class file major/minor version 48.0). Built to run on JDK 1.4 through JDK 8. When executing directly under Java 21 without upgrading, strong Java Platform Module System (JPMS) encapsulation blocks reflection into internal JDK APIs unless explicit command-line flags are configured.

Vulnerabilities & Security Risks
End-of-Life (EOL) since August 2015 with severe unpatched vulnerabilities:

CVE-2019-17571 (CVSS 9.8): Remote Code Execution (RCE) via untrusted deserialization in SocketServer.

CVE-2021-4104: Deserialization vulnerability when configured to use JMSAppender.

CVE-2022-23302: Deserialization vulnerability when configured to use JMSSink.

CVE-2022-23305 (CVSS 9.8): SQL Injection in JDBCAppender.

JVM Command-Line Flag Options (Workarounds for Legacy Log4j 1.2.17 on Java 21)
If you choose not to upgrade dependencies immediately and run the unpatched log4j:log4j:1.2.17 artifact on Java 21, you must pass JVM flags to bypass encapsulation restrictions:

--add-opens=java.base/java.lang=ALL-UNNAMED — Permits reflection into java.lang internals needed by legacy Log4j utilities.

--add-opens=java.base/java.util=ALL-UNNAMED — Grants access to internal collection reflection routines.

-Dsun.util.logging.disableWindowWarning=true — Suppresses legacy reflection warnings on headless/GUI appenders.

Important Note: Passing --add-opens flags resolves Java 21 runtime IllegalAccessException or InaccessibleObjectException errors, but it does not patch or fix any of the severe security CVEs present in Log4j 1.2.17.

Recommended Strategy without Code Rewrite
Upgrade to Log4j 2.x by using the log4j-1.2-api bridge module (org.apache.logging.log4j:log4j-1.2-api) alongside the Log4j 2 core engine. This completely eliminates the need for --add-opens JVM workaround flags and remediates all 1.x vulnerabilities.

Will Upgrade to Log4j 2.x Require Rewriting Code Calls?
NO. Code calls do not need to be rewritten. The log4j-1.2-api bridge intercepts existing org.apache.log4j.* package imports and transparently routes all logging calls directly to the modern Log4j 2 engine. You only need to update your build script dependencies and migrate your configuration file (from log4j.properties/.xml to log4j2.xml).

Maven Build Configuration
XML
<!-- Maven Configuration -->
<dependencies>
    <dependency>
        <groupId>org.apache.logging.log4j</groupId>
        <artifactId>log4j-1.2-api</artifactId>
        <version>2.23.1</version>
    </dependency>
    <dependency>
        <groupId>org.apache.logging.log4j</groupId>
        <artifactId>log4j-api</artifactId>
        <version>2.23.1</version>
    </dependency>
    <dependency>
        <groupId>org.apache.logging.log4j</groupId>
        <artifactId>log4j-core</artifactId>
        <version>2.23.1</version>
    </dependency>
</dependencies>
Gradle Build Configuration
Groovy
// Gradle Configuration
dependencies {
    implementation 'org.apache.logging.log4j:log4j-1.2-api:2.23.1'
    implementation 'org.apache.logging.log4j:log4j-api:2.23.1'
    implementation 'org.apache.logging.log4j:log4j-core:2.23.1'
}
2. Artifact: com.fasterxml.jackson.core:jackson-annotations:2.17.2
Original JDK Target
Java 8 (Class file major version 52.0). Designed as a Multi-Release JAR (MRJAR) with complete Java Platform Module System (JPMS) descriptors (module-info.class under module name com.fasterxml.jackson.annotation). It is fully tested, certified, and compliant with modern JVMs up to Java 21+.

Vulnerabilities & Security Risks
None. Jackson 2.17.2 is an actively maintained release with no known CVEs or security advisories. Unlike Log4j 1.x, this dependency carries zero security vulnerabilities.

JVM Command-Line Flag Options
None required. Unlike legacy libraries, Jackson 2.17.2 adheres strictly to JPMS encapsulation and reflection rules out of the box. You do not need any --add-opens or --add-exports JVM flags when running on Java 21.

Recommended Strategy without Code Rewrite
Keep version 2.17.2 as-is. Ensure that related Jackson modules in your build file (jackson-core and jackson-databind) are aligned to the same 2.17.2 version family or managed via the Jackson BOM (com.fasterxml.jackson:jackson-bom:2.17.2).

Will Upgrade to Java 21 Require Rewriting Code Calls?
NO. All standard annotations (@JsonProperty, @JsonIgnore, @JsonInclude, @JsonCreator, etc.) remain 100% backward compatible. Moving your runtime to Java 21 requires zero code or annotation edits.

Maven Build Configuration
XML
<!-- Maven Configuration -->
<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-annotations</artifactId>
    <version>2.17.2</version>
</dependency>
Gradle Build Configuration
Groovy
// Gradle Configuration
implementation 'com.fasterxml.jackson.core:jackson-annotations:2.17.2'