Just try to run hazelcast 3 (latest of 3.x) on java11. It will log what it needs to be opened up.
T on phone On Tue, Jun 15, 2021, 20:19 Benjamin Marwell <bmarw...@apache.org> wrote: > Tamás, > > which module do you open? > > In most cases I have encountered, adding jaxb as a dependency to the > project is sufficient. But to be sure, we would need to see an example. > > I think this would have long been noticed if it was a common problem. > > Ben > > > On Tue, 15 Jun 2021, 19:18 Tamás Cservenák, <ta...@cservenak.net> wrote: > > > 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 > > > > > >
