Merge log4j-*-java9 modules into log4j-api and log4j-core

[ppkarwasz]

The log4j-api-java9 and log4j-core-java9 modules are a relict from an era where multi-release JAR content could not be produced by the consuming Maven module itself. Each compiled a handful of Java 9 sources (padded with stub classes to satisfy the compiler, since log4j-api-java9 had no dependency on log4j-api), zipped the compiled classes in a classes/META-INF/versions/9 layout, and had the consumer unpack the zip into target at prepare-package.

This PR compiles the Java 9 sources directly in log4j-api and log4j-core instead, using a second maven-compiler-plugin execution over a new src/main/java9 source directory with <release>9</release> and <multiReleaseOutput>true</multiReleaseOutput>, and deletes the two auxiliary modules (including all their stub classes, which are no longer needed: the real classes from target/classes are on the compile classpath).

The published artifacts are unchanged: the versioned class list and the entry sizes in log4j-api.jar and log4j-core.jar are identical before and after (same compiler version, flags and JDK), the Multi-Release: true manifest entry keeps coming from the bnd-multi-release property, and the versioned classes are still compiled at class-file version 53. The new compiler execution stays bound to prepare-package so that bnd-maven-plugin (running at process-classes) never sees the versioned classes — the same timing the zip-unpack mechanism had (cf. apache/logging-parent#93). The existing delete-module-descriptors clean execution keeps incremental no-clean builds correct.

Other clean-ups that fall out of this:

• the dead build-helper-maven-plugin add-source executions in both consumers (they added a target/log4j-*-java9 directory that never existed) are removed;
• the dependencyManagement entries for the zip artifacts in log4j-parent are removed (they were never in the published BOM, cf. LOG4J2-3241).

Tests: the Java 9 StackLocator tests move to log4j-api-test as a maven-failsafe-plugin integration test (StackLocatorJava9IT) that runs against the packaged multi-release JAR, with a guard assertion that the META-INF/versions/9 variant of StackLocator is actually loaded. Two remarks:

• The two getCurrentStackTrace tests are dropped, not moved: they only passed against the old module's stubbed PrivateSecurityManagerStackTraceUtil (whose isEnabled() returned false). Against the real classes on JDK 17 they exercise the SecurityManager path, which StackLocatorUtilTest already covers. The Java 9 ProcessIdUtilTest was assertion-identical to the existing one in log4j-api-test and is dropped too.
• The failsafe execution is restricted to the new java9 package, because the pre-existing (and currently never executed) StackLocatorTestIT installs a SecurityManager and fails on JDK 17 without -Djava.security.manager=allow; reviving it is a separate follow-up.

Visible losses:

• the moved sources in src/main/java9 now fall outside the default src/main/java globs of Spotless and RAT, so they lose automatic format/license-header enforcement (9 stable files; an <includes> override in logging-parent or here is possible as a follow-up);
• the Java 9 sources are, as before, absent from the published sources JARs.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RTbXEN6DStfnmMLSMPWM9b

[ppkarwasz]

This is a test for 2026-era IDEs. Do they support multi-version Maven modules or not?