[SUREFIRE-1909] Support JUnit 5 reflection access by changing add-exports to add-opens

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 3.0.0-M5
• Fix Version/s: 2.22.3, 3.0.0-M6
• Component/s: JUnit 5.x support
• Assignee: Tibor Digana
• Reporter: Christian Kohlschütter
• Created: 22/Apr/21 02:42
• Updated: 18/Feb/22 07:51
• Resolved: 17/Feb/22 05:58

Description

Testing JUnit 5 classes of a JPMS-enabled project with Surefire may fail if a test class (or, for example, an abstract test base class) is not declared "public". I'm seeing the following error:

 

java.lang.reflect.InaccessibleObjectException: Unable to make public static void some.package.SomeClass.setupClass() throws java.io.IOException accessible: module some.module does not "opens some.package" to unnamed module @754ba872

This could be fixed by adding the recommended "opens some.package" to the project's module-info.java, however that is undesirable since it changes the project's behavior beyond just unit testing. Adding a secondary "test-only" module-info.java is also counterproductive since not all IDEs support this, and these two files would have to be kept in sync, which is non-trivial.

An easy fix would be to change the "-add-exports" VM parameter that surefire adds automatically to "-add-opens" in maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/ModularClasspathForkConfiguration.java

This bug is particularly bad because PMD now specifically complains about junit5 classes marked as public instead of package-private; see https://pmd.github.io/2021/05/29/PMD-6.35.0/

Issue Links

• links to: GitHub Pull Request #461
• links to: GitHub Pull Request #471
• links to: GitHub Pull Request #473