Fix jdk21 tests

[Jayesh45-master]

Fixes #11398

Pull Request: Fix JDK 21+ test failures by propagating --add-opens to forked test JVM

Fixes #11398

Overview

This pull request fixes test failures on JDK 21+ caused by missing module opens
in the forked Surefire JVM.

The change ensures that required --add-opens options are propagated correctly
alongside the JaCoCo agent using Surefire’s supported @{jacocoArgLine} mechanism.

Note:
This pull request has been rebased onto the maven-3.9.x branch as requested,
since issue #11398 is reported against Maven 3.9.9. The branch was force-pushed
after rebasing, without introducing any additional changes.

What this PR does

• Appends required --add-opens JVM options to the existing Surefire argLine
• Preserves the current JaCoCo setup and forked JVM behavior
• Ensures tests relying on reflective access continue to work on JDK 21+

Why this change is needed

Starting with JDK 21, Java enforces strong module encapsulation more strictly.
Tests that rely on reflective access to JDK internals (for example
java.lang and java.lang.reflect) fail with InaccessibleObjectException
unless the corresponding modules are explicitly opened at JVM startup.

Although the build already used @{jacocoArgLine} to inject the JaCoCo agent,
the forked test JVM did not receive the required --add-opens options.
As a result, tests passed on JDK 17 but failed on JDK 21+.

This change ensures the required JVM options are present at fork time,
which is the only point where module opens are honored by the JVM.

How the change works

The Surefire argLine configuration is extended to include the required
--add-opens options in addition to @{jacocoArgLine}.

This approach:

• Uses documented Surefire behavior
• Avoids illegal reflective access at runtime
• Keeps the change scoped strictly to test execution

No production code behavior is affected.

Testing

• Verified locally with mvn verify on JDK 17 and JDK 21
• On JDK 22+, some Maven Core tests fail due to Guice/Sisu injection behavior
  unrelated to this change

Checklist

• Single issue addressed
• Clear PR description
• Meaningful commit
• Existing tests fail without this change and pass once applied
• mvn verify run (JDK 17 / 21)
• Core ITs (executed by CI)

License Declaration

• I hereby declare this contribution to be licensed under the
  Apache License Version 2.0, January 2004

[desruisseaux]

The first commit of this pull request is #11604. Not necessarily a problem, but it should be noted that #11604 would need to be merged first.

Also those two pull requests should be on the top of the master branch rather than maven-4.0.x. No need to close these pull requests. You can get a clone of the master branch, cherry-pick the commits (take this opportunity for making the two pull requests independent), push --force on your clone, click on "edit" on the top of this page, and on the line "Jayesh45-master wants to merge 2 commits into apache:maven-4.0.x" swich back "maven-4.0.x" to "master".

[desruisseaux]

Corrections to my previous comment: #11398 said that the issue is reported against Maven 3.9.9. In such case, this pull request needs to be rebased not on master or maven-4.0.x, but on the maven-3.9.x branch (I presume, would need confirmation by a Maven core developer).

[Jayesh45-master]

@desruisseaux
So sir like i have to do the changes in maven.3.x and submit again the pull request

[desruisseaux]

No need to create a new pull request. You can cherry-pick, push force and then click on the "edit" button of this pull request.

[Jayesh45-master]

Hi @desruisseaux ,

I’ve updated the pull request based on the discussion and rebased it onto the
maven-3.9.x branch, since the issue is reported against Maven 3.9.9.
The changes are limited to ensuring the required --add-opens options are
propagated to the forked test JVM alongside the existing JaCoCo setup.

Could you please review the updated changes when you have a moment?
Thanks for your time and guidance.