In my case, it was a test in mvnd which is using some low level reflection. I do agree this is not the best example, because an easy workaround can be done by configuring surefire to use a fork. However, if a plugin does the same thing, there's no easy way to workaround it.
Le mar. 15 juin 2021 à 19:04, Robert Scholte <rfscho...@apache.org> a écrit : > AFAIK the --add-opens is only useful when using the module path. Maven > itself and the plugins use the classpath, so I would like to have an > example to better understand your issue. > As others explained, --add-opens allow overriding the default accessibility. For example if you get a private field on a JDK class and use setAccessible using reflection, you may run into an exception that would require adding this --add-opens argument on JDK 11 or more. They are not required on JDK 8 and the annoying thing is that the option causes the JVM to fail. Using forked JVM from inside plugins does work around the problem, but only when that's possible ;-) > > thanks, > Robert > On 15-6-2021 18:43:35, Guillaume Nodet <gno...@apache.org> wrote: > Hi everyone ! > > There are some small incompatibilities between JDK around the supported > command line versions. Usually, those do not cause any real problems. > However, the "--add-opens" are sometimes necessary and only supported on > JDK >= 9, as the JVM exits with an error on JDK 8. > Some plugins may require the use of those options when running on JDK >= > 9. What would be the way to solve this ? > > For mvnd, when the client launches the daemon, the JDK_JAVA_OPTIONS > environment property is used. But it works because we have control on the > client environment. But when you just clone a git repo, asking the user to > set a specific environment is problematic imho. The .mvn/maven.config or > .mvn/jvm.config can't be used to set up environment variables or to > conditionally set up arguments afaik. > > Any idea ? > > -- > ------------------------ > Guillaume Nodet > -- ------------------------ Guillaume Nodet
