[
https://issues.apache.org/jira/browse/SUREFIRE-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16661262#comment-16661262
]
Petr Dolezal edited comment on SUREFIRE-1531 at 10/23/18 8:50 PM:
------------------------------------------------------------------
I hope my two cents hits the right target: I experienced very similar problem
with {{IllegalAccessError}} as described above as well, but it was plain JUnit
5 test.
After a while of exploring, I found out that the problem disappears when
anything that JUnit needs to touch with reflection, e.g., {{@Test}} methods or
methods for {{@MethodSource}} is public and the package is exported. Of course,
this is not very good and for not exported packages it is completely useless.
However, I peeked at the command line that Surefire produces to run the tests
and I tried to run the commands manually. I believe that the problem could be
fixed actually quite easily. Instead of just {{\-\-add-exports}} a more
powerful {{\-\-add-opens}} switch can do the trick as it effectively enables
almighty reflection for the code. Then JUnit worked fine again and could access
even non-public members.
was (Author: pdolezal):
I hope my two cents hits the right target: I experienced very similar problem
with {{IllegalAccessError}} as described above as well, but it was plain JUnit
5 test.
After a while of exploring, I found out that the problem disappears when
anything that JUnit needs to touch with reflection, e.g., {{@Test}} methods or
methods for {{@MethodSource}} is public and the package is exported. Of course,
this is not very good and for not exported packages it is completely useless.
However, I peeked at the command line that Surefire produces to run the tests
and I tried to run the commands manually. I believe that the problem could be
fixed actually quite easily. Instead of just {{--add-exports}} a more powerful
{{--add-opens}} switch can do the trick as it effectively enables almighty
reflection for the code. Then JUnit worked fine again and could access even
non-public members.
> Option to switch-off Java 9 modules
> -----------------------------------
>
> Key: SUREFIRE-1531
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1531
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
> Affects Versions: 2.22.0
> Reporter: Lukáš Křečan
> Priority: Major
>
> I am working on a library and I am adding support for Java 9 modules.
> Surefire 2.21.0 by default executes tests with Java 9 modules switched-on if
> it detects module-info.java While it may make sense in some cases, in my case
> I'd like the switch it off.
> The reason is simple. I am using Mockito to mock an interface that extends a
> Spring interface. Mockito has to create an implementation of this interface
> (proxy or subclass) and for this it needs to have access to the Spring
> interfaces. If Java 9 modules are enabled for the tests I have to manually
> add each such dependencies to Surefire configuration, which does not make
> much sense. To makes things worse, the interface actually extends two Spring
> interfaces form two different Spring modules so the configuration is almost
> impossible to get right.
> So far I am at ( and I am still getting IllegalAccessErrors)
> {code:java}
> --add-exports spring.context/org.springframework.scheduling=org.mockito
> --add-exports spring.beans/org.springframework.beans.factory=org.mockito
> {code}
> I would prefer to switch-off the Java 9 modules for the test module
> altogether (same behavior as pre 2.21.0)
>
> The test is here
> [https://github.com/lukas-krecan/ShedLock/blob/java9/shedlock-spring/src/test/java/net/javacrumbs/shedlock/spring/CleanupTest.java]
>
> If you want, I can send a pull request.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
