Howdy, Robert, I think you are wrong:
from Java 11 migration guide --add-opens If you have to allow code on the class path to do deep reflection to access nonpublic members, then use the --add-opens runtime option. Some libraries do deep reflection, meaning setAccessible(true), so they can access all members, including private ones. You can grant this access using the --add-opens option on the java command line. No warning messages are generated as a result of using this option. Hence, it is needed even for CP applications, that do require "deep reflection". HTH Tamas On Tue, Jun 15, 2021 at 7:04 PM Robert Scholte <rfscho...@apache.org> wrote: > 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. > > 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 >
