Re: Supporting building with incompatible JDK versions on a single project
The example given by Guillaume looks interesting. jre-options = ${jre-${java.specification.version}-options:-${jre-default-options}} jre-default-options = [default options] jre-1.8 = [my JDK 1.8 specific options] But I would maybe distinguish between: 1. Maven options 2. and plugin options And to be more specific, the first case (1) may have more alternatives with [root]/.mvn/jvm.config. Example: 1. [root]/.mvn/jvm9.config 2. [root]/.mvn/jvm11.config 3. [root]/.mvn/jvm16.config It does not make sense to have "--add-opens" and similar things in the jvm.config for plugins (2) because the lifecycle and plugins are complex. We should not end up with a kind of config structure in the jvm.config. Due to this we have POM structure. Perhaps the POM should have new non/transitive entry points dedicated for the phases of the build life cycle rather than parameters (entry points) in the plugins. I believe the users would be lucky if e.g. JUnit5 BOM (one for compile, runtime, another for test and test-compile) would have these entry points (as a recommendation from the OSS groups) and the user would just use it without writing "--add-reads ... --add-exports ... --add-opens ... --add-modules ... etc.". Cheers Tibor On Wed, Jun 16, 2021 at 2:27 PM Guillaume Nodet wrote: > Le mer. 16 juin 2021 à 14:04, Romain Manni-Bucau a > écrit : > > > Le mer. 16 juin 2021 à 13:53, Guillaume Nodet a > écrit > > : > > > > > Le mer. 16 juin 2021 à 13:39, Romain Manni-Bucau < > rmannibu...@gmail.com> > > a > > > écrit : > > > > > > > Le mer. 16 juin 2021 à 12:05, Guillaume Nodet a > > > écrit > > > > : > > > > > > > > > A few plugins that fail with the same problem found by googling a > > bit: > > > > > https://youtrack.jetbrains.com/issue/IDEA-266556 > > > > > https://github.com/projectlombok/lombok/issues/2681 > > > > > > > > > > > > > > > > > > > > > > > > > https://community.sonarsource.com/t/maven-sonar-scanner-not-working-with-jdk-16/40699 > > > > > > > > > > > > > > > > > > > > > > > > > https://www.bountysource.com/issues/97382407-enunciate-does-not-run-on-jdk16 > > > > > That's just the first page on google... so I don't think this is me > > > > running > > > > > into a corner case. JDK 16 has only been release 2 months ago, and > > the > > > > > rules have changed quite a bit since JDK 15, so that's not an old > > > > problem, > > > > > it's a new one. > > > > > > > > > > > > > All these ones are solved with MAVEN_OPTS AFAIK so it is already in - > > > > understand we can't have the correct jpms options by default since > > we'll > > > > never know all plugins. > > > > > > > > Maybe I'm the only one, but when I see a project with a pom.xml and I > > > just > > > want to build it, the first thing I try is `mvn install -DskipTests`. > > This > > > work in most of the case, and I think it should stay that way. That's > why > > > I'm looking for a way to configure those options per-project. > > > > > > So yes, that's right, MAVEN_OPTS may solve the problem. But that does > > not > > > solve my problem which is: > > > * how to set up the environment (maven options or jvm options or > > > eventually environment variable) > > > * with a config per project (not at the maven installation level) > > > * with something that can have a bit of logic so that it can depend > on > > > which jdk version is used > > > > > > > setenv.sh in multimoduleroot/.mvn ;) > > > > > Actually, thinking about it, this also raises a few problems. It makes the > life for tools embedding maven much more complicated. > I'm wondering if a configuration based solution wouldn't be easier to work > with (i.e. without having to interpret or spawn a command shell) ? > > In felix / karaf, the problem was solved by using property files and > property substitution. This could look like: > jre-options = > ${jre-${java.specification.version}-options:-${jre-default-options}} > jre-default-options = [default options] > jre-1.8 = [my JDK 1.8 specific options] > > This kind of configuration allows you to lay out a bit of logic in the > configuration. > This is just an example of course, but it would be more inlined with the > [root]/.mvn/jvm.config and like. > > Guillaume > > > > > > > > > > > > > > > > > > > > > > > > > I think adding the --illegal-access=permit option on the command is > > > > > sufficient to solve all those problems, but the problem is still > the > > > > same : > > > > > this option will break if using JDK 1.8. This has to be configured > > on > > > > the > > > > > project and not globally. > > > > > > > > > > > > > This will likely break soon so I wouldn't consider it as an option. > > > > > > > > > > See above, I'm not looking for maven to fix the problem. I'm looking > for > > > maven to provide a way to fix the problem. Which implies, the exact > > option > > > to configure is up to the user, so the fact that is already deprecated > is > > > irrelevant. > > > > > > > > > > > > > > > > > > > > > I'm not sure
Re: Supporting building with incompatible JDK versions on a single project
Le mer. 16 juin 2021 à 14:27, Guillaume Nodet a écrit : > Le mer. 16 juin 2021 à 14:04, Romain Manni-Bucau a > écrit : > > > Le mer. 16 juin 2021 à 13:53, Guillaume Nodet a > écrit > > : > > > > > Le mer. 16 juin 2021 à 13:39, Romain Manni-Bucau < > rmannibu...@gmail.com> > > a > > > écrit : > > > > > > > Le mer. 16 juin 2021 à 12:05, Guillaume Nodet a > > > écrit > > > > : > > > > > > > > > A few plugins that fail with the same problem found by googling a > > bit: > > > > > https://youtrack.jetbrains.com/issue/IDEA-266556 > > > > > https://github.com/projectlombok/lombok/issues/2681 > > > > > > > > > > > > > > > > > > > > > > > > > https://community.sonarsource.com/t/maven-sonar-scanner-not-working-with-jdk-16/40699 > > > > > > > > > > > > > > > > > > > > > > > > > https://www.bountysource.com/issues/97382407-enunciate-does-not-run-on-jdk16 > > > > > That's just the first page on google... so I don't think this is me > > > > running > > > > > into a corner case. JDK 16 has only been release 2 months ago, and > > the > > > > > rules have changed quite a bit since JDK 15, so that's not an old > > > > problem, > > > > > it's a new one. > > > > > > > > > > > > > All these ones are solved with MAVEN_OPTS AFAIK so it is already in - > > > > understand we can't have the correct jpms options by default since > > we'll > > > > never know all plugins. > > > > > > > > Maybe I'm the only one, but when I see a project with a pom.xml and I > > > just > > > want to build it, the first thing I try is `mvn install -DskipTests`. > > This > > > work in most of the case, and I think it should stay that way. That's > why > > > I'm looking for a way to configure those options per-project. > > > > > > So yes, that's right, MAVEN_OPTS may solve the problem. But that does > > not > > > solve my problem which is: > > > * how to set up the environment (maven options or jvm options or > > > eventually environment variable) > > > * with a config per project (not at the maven installation level) > > > * with something that can have a bit of logic so that it can depend > on > > > which jdk version is used > > > > > > > setenv.sh in multimoduleroot/.mvn ;) > > > > > Actually, thinking about it, this also raises a few problems. It makes the > life for tools embedding maven much more complicated. > I'm wondering if a configuration based solution wouldn't be easier to work > with (i.e. without having to interpret or spawn a command shell) ? > > In felix / karaf, the problem was solved by using property files and > property substitution. This could look like: > jre-options = > ${jre-${java.specification.version}-options:-${jre-default-options}} > jre-default-options = [default options] > jre-1.8 = [my JDK 1.8 specific options] > > This kind of configuration allows you to lay out a bit of logic in the > configuration. > This is just an example of course, but it would be more inlined with the > [root]/.mvn/jvm.config and like. > Thing is that we can't handle this file cleanly (as seen in the system property thread) so maven would be broken. Now i'm not very worried about embedded tools, it is trivial to execute the script and get MAVEN_OPTS set properly for most tools (thinking to the mainstream IDE and mvnd to explicit what I have in mind). Worse case it is not different than today where a few of IDE just ignores it without making too much issue in user land AFAIK so let's say it is just more limiting than helping for most cases since it would be way more work to setup properly than just forcing some options which is known by anyone IMHO. > > Guillaume > > > > > > > > > > > > > > > > > > > > > > > > > I think adding the --illegal-access=permit option on the command is > > > > > sufficient to solve all those problems, but the problem is still > the > > > > same : > > > > > this option will break if using JDK 1.8. This has to be configured > > on > > > > the > > > > > project and not globally. > > > > > > > > > > > > > This will likely break soon so I wouldn't consider it as an option. > > > > > > > > > > See above, I'm not looking for maven to fix the problem. I'm looking > for > > > maven to provide a way to fix the problem. Which implies, the exact > > option > > > to configure is up to the user, so the fact that is already deprecated > is > > > irrelevant. > > > > > > > > > > > > > > > > > > > > > I'm not sure what you refer to with the setenv.sh script ? is that > > > > > something that maven launcher runs prior to launching the JVM ? > > > > > > > > > > > > > Yes, it is often used in servers (thinking to tomcat or karaf). > > > > mvn.sh (similarly for .bat flavor) would source bin/setenv.sh (bat) > if > > > > exists. > > > > > > > > this script would container any logic the user wants and be usable to > > > setup > > > > maven env vars before the script reads it. > > > > > > > > a common (trivial) setup would be (a more advanced can test java > > > > --version): > > > > > > > > bin/setenv.sh: > > > > #!
Re: Supporting building with incompatible JDK versions on a single project
Le mer. 16 juin 2021 à 14:04, Romain Manni-Bucau a écrit : > Le mer. 16 juin 2021 à 13:53, Guillaume Nodet a écrit > : > > > Le mer. 16 juin 2021 à 13:39, Romain Manni-Bucau > a > > écrit : > > > > > Le mer. 16 juin 2021 à 12:05, Guillaume Nodet a > > écrit > > > : > > > > > > > A few plugins that fail with the same problem found by googling a > bit: > > > > https://youtrack.jetbrains.com/issue/IDEA-266556 > > > > https://github.com/projectlombok/lombok/issues/2681 > > > > > > > > > > > > > > > > > > https://community.sonarsource.com/t/maven-sonar-scanner-not-working-with-jdk-16/40699 > > > > > > > > > > > > > > > > > > https://www.bountysource.com/issues/97382407-enunciate-does-not-run-on-jdk16 > > > > That's just the first page on google... so I don't think this is me > > > running > > > > into a corner case. JDK 16 has only been release 2 months ago, and > the > > > > rules have changed quite a bit since JDK 15, so that's not an old > > > problem, > > > > it's a new one. > > > > > > > > > > All these ones are solved with MAVEN_OPTS AFAIK so it is already in - > > > understand we can't have the correct jpms options by default since > we'll > > > never know all plugins. > > > > > > Maybe I'm the only one, but when I see a project with a pom.xml and I > > just > > want to build it, the first thing I try is `mvn install -DskipTests`. > This > > work in most of the case, and I think it should stay that way. That's why > > I'm looking for a way to configure those options per-project. > > > > So yes, that's right, MAVEN_OPTS may solve the problem. But that does > not > > solve my problem which is: > > * how to set up the environment (maven options or jvm options or > > eventually environment variable) > > * with a config per project (not at the maven installation level) > > * with something that can have a bit of logic so that it can depend on > > which jdk version is used > > > > setenv.sh in multimoduleroot/.mvn ;) > > Actually, thinking about it, this also raises a few problems. It makes the life for tools embedding maven much more complicated. I'm wondering if a configuration based solution wouldn't be easier to work with (i.e. without having to interpret or spawn a command shell) ? In felix / karaf, the problem was solved by using property files and property substitution. This could look like: jre-options = ${jre-${java.specification.version}-options:-${jre-default-options}} jre-default-options = [default options] jre-1.8 = [my JDK 1.8 specific options] This kind of configuration allows you to lay out a bit of logic in the configuration. This is just an example of course, but it would be more inlined with the [root]/.mvn/jvm.config and like. Guillaume > > > > > > > > > > > > > > > > > I think adding the --illegal-access=permit option on the command is > > > > sufficient to solve all those problems, but the problem is still the > > > same : > > > > this option will break if using JDK 1.8. This has to be configured > on > > > the > > > > project and not globally. > > > > > > > > > > This will likely break soon so I wouldn't consider it as an option. > > > > > > > See above, I'm not looking for maven to fix the problem. I'm looking for > > maven to provide a way to fix the problem. Which implies, the exact > option > > to configure is up to the user, so the fact that is already deprecated is > > irrelevant. > > > > > > > > > > > > > > > > I'm not sure what you refer to with the setenv.sh script ? is that > > > > something that maven launcher runs prior to launching the JVM ? > > > > > > > > > > Yes, it is often used in servers (thinking to tomcat or karaf). > > > mvn.sh (similarly for .bat flavor) would source bin/setenv.sh (bat) if > > > exists. > > > > > > this script would container any logic the user wants and be usable to > > setup > > > maven env vars before the script reads it. > > > > > > a common (trivial) setup would be (a more advanced can test java > > > --version): > > > > > > bin/setenv.sh: > > > #! /bin/sh > > > epxort MAVEN_OPTS=--illegal-access=permit > > > > > > > > So could we enhance the maven shell script to look for a > > [project-root]/.mvn/setenv.sh and call it ? That would definitely solve > > the problem. > > > > +1 > > > > > > > > > > > > > > > > > Le mer. 16 juin 2021 à 09:55, Romain Manni-Bucau < > > rmannibu...@gmail.com> > > > a > > > > écrit : > > > > > > > > > Le mer. 16 juin 2021 à 08:39, Guillaume Nodet > a > > > > écrit > > > > > : > > > > > > > > > > > Well, my point was not really to find a workaround, but rather to > > > > start a > > > > > > discussion around "maven jvm customization from files is not well > > > > > > supported for now" ... :-) > > > > > > > > > > > > > > > > Got it, but point is "is it that often needed"? > > > > > Most plugin using toolchain or equivalent can have JVM > customization > > > > > (already) and it is trivial to handle per jvm config through > > profiles. > > > > > So at the end it is only about maven
Re: Supporting building with incompatible JDK versions on a single project
Le mer. 16 juin 2021 à 13:53, Guillaume Nodet a écrit : > Le mer. 16 juin 2021 à 13:39, Romain Manni-Bucau a > écrit : > > > Le mer. 16 juin 2021 à 12:05, Guillaume Nodet a > écrit > > : > > > > > A few plugins that fail with the same problem found by googling a bit: > > > https://youtrack.jetbrains.com/issue/IDEA-266556 > > > https://github.com/projectlombok/lombok/issues/2681 > > > > > > > > > > > > https://community.sonarsource.com/t/maven-sonar-scanner-not-working-with-jdk-16/40699 > > > > > > > > > > > > https://www.bountysource.com/issues/97382407-enunciate-does-not-run-on-jdk16 > > > That's just the first page on google... so I don't think this is me > > running > > > into a corner case. JDK 16 has only been release 2 months ago, and the > > > rules have changed quite a bit since JDK 15, so that's not an old > > problem, > > > it's a new one. > > > > > > > All these ones are solved with MAVEN_OPTS AFAIK so it is already in - > > understand we can't have the correct jpms options by default since we'll > > never know all plugins. > > > > Maybe I'm the only one, but when I see a project with a pom.xml and I > just > want to build it, the first thing I try is `mvn install -DskipTests`. This > work in most of the case, and I think it should stay that way. That's why > I'm looking for a way to configure those options per-project. > > So yes, that's right, MAVEN_OPTS may solve the problem. But that does not > solve my problem which is: > * how to set up the environment (maven options or jvm options or > eventually environment variable) > * with a config per project (not at the maven installation level) > * with something that can have a bit of logic so that it can depend on > which jdk version is used > setenv.sh in multimoduleroot/.mvn ;) > > > > > > > > > > > I think adding the --illegal-access=permit option on the command is > > > sufficient to solve all those problems, but the problem is still the > > same : > > > this option will break if using JDK 1.8. This has to be configured on > > the > > > project and not globally. > > > > > > > This will likely break soon so I wouldn't consider it as an option. > > > > See above, I'm not looking for maven to fix the problem. I'm looking for > maven to provide a way to fix the problem. Which implies, the exact option > to configure is up to the user, so the fact that is already deprecated is > irrelevant. > > > > > > > > > > > I'm not sure what you refer to with the setenv.sh script ? is that > > > something that maven launcher runs prior to launching the JVM ? > > > > > > > Yes, it is often used in servers (thinking to tomcat or karaf). > > mvn.sh (similarly for .bat flavor) would source bin/setenv.sh (bat) if > > exists. > > > > this script would container any logic the user wants and be usable to > setup > > maven env vars before the script reads it. > > > > a common (trivial) setup would be (a more advanced can test java > > --version): > > > > bin/setenv.sh: > > #! /bin/sh > > epxort MAVEN_OPTS=--illegal-access=permit > > > > > So could we enhance the maven shell script to look for a > [project-root]/.mvn/setenv.sh and call it ? That would definitely solve > the problem. > +1 > > > > > > > > > > Le mer. 16 juin 2021 à 09:55, Romain Manni-Bucau < > rmannibu...@gmail.com> > > a > > > écrit : > > > > > > > Le mer. 16 juin 2021 à 08:39, Guillaume Nodet a > > > écrit > > > > : > > > > > > > > > Well, my point was not really to find a workaround, but rather to > > > start a > > > > > discussion around "maven jvm customization from files is not well > > > > > supported for now" ... :-) > > > > > > > > > > > > > Got it, but point is "is it that often needed"? > > > > Most plugin using toolchain or equivalent can have JVM customization > > > > (already) and it is trivial to handle per jvm config through > profiles. > > > > So at the end it is only about maven "embedded" plugins and maven > > itself. > > > > Last one shouldnt need anything and first ones are solved by forcing > a > > > JVM > > > > version for the main build (which does not prevent to run tests and > > > graalvm > > > > native-image with 50 different JVMs). > > > > > > > > The setenv.sh/bat option seems like an acceptable compromise for > these > > > > border cases but not sure we need anything more fancy. > > > > What I would be really against is a jvm.config like solution which > does > > > not > > > > enable to use any configuration (we can't use space for example right > > now > > > > in system properties so if we get the same limitation for env vars it > > > would > > > > be pointless IMHO). > > > > > > > > Hope it makes sense. > > > > > > > > > > > > > > > > > > Le mer. 16 juin 2021 à 07:24, Romain Manni-Bucau < > > > rmannibu...@gmail.com> > > > > a > > > > > écrit : > > > > > > > > > > > Le mar. 15 juin 2021 à 23:39, Guillaume Nodet > > > a > > > > > écrit > > > > > > : > > > > > > > > > > > > > In my case, it was a test in mvnd which is using some low level > > > >
Re: Supporting building with incompatible JDK versions on a single project
Le mer. 16 juin 2021 à 13:39, Romain Manni-Bucau a écrit : > Le mer. 16 juin 2021 à 12:05, Guillaume Nodet a écrit > : > > > A few plugins that fail with the same problem found by googling a bit: > > https://youtrack.jetbrains.com/issue/IDEA-266556 > > https://github.com/projectlombok/lombok/issues/2681 > > > > > > > https://community.sonarsource.com/t/maven-sonar-scanner-not-working-with-jdk-16/40699 > > > > > > > https://www.bountysource.com/issues/97382407-enunciate-does-not-run-on-jdk16 > > That's just the first page on google... so I don't think this is me > running > > into a corner case. JDK 16 has only been release 2 months ago, and the > > rules have changed quite a bit since JDK 15, so that's not an old > problem, > > it's a new one. > > > > All these ones are solved with MAVEN_OPTS AFAIK so it is already in - > understand we can't have the correct jpms options by default since we'll > never know all plugins. > > Maybe I'm the only one, but when I see a project with a pom.xml and I just want to build it, the first thing I try is `mvn install -DskipTests`. This work in most of the case, and I think it should stay that way. That's why I'm looking for a way to configure those options per-project. So yes, that's right, MAVEN_OPTS may solve the problem. But that does not solve my problem which is: * how to set up the environment (maven options or jvm options or eventually environment variable) * with a config per project (not at the maven installation level) * with something that can have a bit of logic so that it can depend on which jdk version is used > > > > > I think adding the --illegal-access=permit option on the command is > > sufficient to solve all those problems, but the problem is still the > same : > > this option will break if using JDK 1.8. This has to be configured on > the > > project and not globally. > > > > This will likely break soon so I wouldn't consider it as an option. > See above, I'm not looking for maven to fix the problem. I'm looking for maven to provide a way to fix the problem. Which implies, the exact option to configure is up to the user, so the fact that is already deprecated is irrelevant. > > > > > > I'm not sure what you refer to with the setenv.sh script ? is that > > something that maven launcher runs prior to launching the JVM ? > > > > Yes, it is often used in servers (thinking to tomcat or karaf). > mvn.sh (similarly for .bat flavor) would source bin/setenv.sh (bat) if > exists. > > this script would container any logic the user wants and be usable to setup > maven env vars before the script reads it. > > a common (trivial) setup would be (a more advanced can test java > --version): > > bin/setenv.sh: > #! /bin/sh > epxort MAVEN_OPTS=--illegal-access=permit > > So could we enhance the maven shell script to look for a [project-root]/.mvn/setenv.sh and call it ? That would definitely solve the problem. > > > > > Le mer. 16 juin 2021 à 09:55, Romain Manni-Bucau > a > > écrit : > > > > > Le mer. 16 juin 2021 à 08:39, Guillaume Nodet a > > écrit > > > : > > > > > > > Well, my point was not really to find a workaround, but rather to > > start a > > > > discussion around "maven jvm customization from files is not well > > > > supported for now" ... :-) > > > > > > > > > > Got it, but point is "is it that often needed"? > > > Most plugin using toolchain or equivalent can have JVM customization > > > (already) and it is trivial to handle per jvm config through profiles. > > > So at the end it is only about maven "embedded" plugins and maven > itself. > > > Last one shouldnt need anything and first ones are solved by forcing a > > JVM > > > version for the main build (which does not prevent to run tests and > > graalvm > > > native-image with 50 different JVMs). > > > > > > The setenv.sh/bat option seems like an acceptable compromise for these > > > border cases but not sure we need anything more fancy. > > > What I would be really against is a jvm.config like solution which does > > not > > > enable to use any configuration (we can't use space for example right > now > > > in system properties so if we get the same limitation for env vars it > > would > > > be pointless IMHO). > > > > > > Hope it makes sense. > > > > > > > > > > > > > > Le mer. 16 juin 2021 à 07:24, Romain Manni-Bucau < > > rmannibu...@gmail.com> > > > a > > > > écrit : > > > > > > > > > Le mar. 15 juin 2021 à 23:39, Guillaume Nodet > a > > > > écrit > > > > > : > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > Guess the most trivial workaround is to replace the plugin by a > > custom > > > > exec > > > > > one propagating maven current
Re: Supporting building with incompatible JDK versions on a single project
Le mer. 16 juin 2021 à 12:05, Guillaume Nodet a écrit : > A few plugins that fail with the same problem found by googling a bit: > https://youtrack.jetbrains.com/issue/IDEA-266556 > https://github.com/projectlombok/lombok/issues/2681 > > > https://community.sonarsource.com/t/maven-sonar-scanner-not-working-with-jdk-16/40699 > > > https://www.bountysource.com/issues/97382407-enunciate-does-not-run-on-jdk16 > That's just the first page on google... so I don't think this is me running > into a corner case. JDK 16 has only been release 2 months ago, and the > rules have changed quite a bit since JDK 15, so that's not an old problem, > it's a new one. > All these ones are solved with MAVEN_OPTS AFAIK so it is already in - understand we can't have the correct jpms options by default since we'll never know all plugins. > > I think adding the --illegal-access=permit option on the command is > sufficient to solve all those problems, but the problem is still the same : > this option will break if using JDK 1.8. This has to be configured on the > project and not globally. > This will likely break soon so I wouldn't consider it as an option. > > I'm not sure what you refer to with the setenv.sh script ? is that > something that maven launcher runs prior to launching the JVM ? > Yes, it is often used in servers (thinking to tomcat or karaf). mvn.sh (similarly for .bat flavor) would source bin/setenv.sh (bat) if exists. this script would container any logic the user wants and be usable to setup maven env vars before the script reads it. a common (trivial) setup would be (a more advanced can test java --version): bin/setenv.sh: #! /bin/sh epxort MAVEN_OPTS=--illegal-access=permit > > Le mer. 16 juin 2021 à 09:55, Romain Manni-Bucau a > écrit : > > > Le mer. 16 juin 2021 à 08:39, Guillaume Nodet a > écrit > > : > > > > > Well, my point was not really to find a workaround, but rather to > start a > > > discussion around "maven jvm customization from files is not well > > > supported for now" ... :-) > > > > > > > Got it, but point is "is it that often needed"? > > Most plugin using toolchain or equivalent can have JVM customization > > (already) and it is trivial to handle per jvm config through profiles. > > So at the end it is only about maven "embedded" plugins and maven itself. > > Last one shouldnt need anything and first ones are solved by forcing a > JVM > > version for the main build (which does not prevent to run tests and > graalvm > > native-image with 50 different JVMs). > > > > The setenv.sh/bat option seems like an acceptable compromise for these > > border cases but not sure we need anything more fancy. > > What I would be really against is a jvm.config like solution which does > not > > enable to use any configuration (we can't use space for example right now > > in system properties so if we get the same limitation for env vars it > would > > be pointless IMHO). > > > > Hope it makes sense. > > > > > > > > > > Le mer. 16 juin 2021 à 07:24, Romain Manni-Bucau < > rmannibu...@gmail.com> > > a > > > écrit : > > > > > > > Le mar. 15 juin 2021 à 23:39, Guillaume Nodet a > > > écrit > > > > : > > > > > > > > > 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. > > > > > > > > > > > > > Guess the most trivial workaround is to replace the plugin by a > custom > > > exec > > > > one propagating maven current context in an extension and forking the > > > > plugin run since maven jvm customization from files is not well > > supported > > > > for now or would need some more advanced script which could source an > > > > optional setenv to set maven_opts but this last one would test java > > > version > > > > which is never great to launch a build and would require to test args > > > "the > > > > maven way" (phase, plugin:goal, plugin:goal@exec) to bypass it when > > > > possible. > > > > > > > > > > > > > Le mar. 15 juin 2021 à 19:04, Robert Scholte > > > 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
Re: Supporting building with incompatible JDK versions on a single project
A few plugins that fail with the same problem found by googling a bit: https://youtrack.jetbrains.com/issue/IDEA-266556 https://github.com/projectlombok/lombok/issues/2681 https://community.sonarsource.com/t/maven-sonar-scanner-not-working-with-jdk-16/40699 https://www.bountysource.com/issues/97382407-enunciate-does-not-run-on-jdk16 That's just the first page on google... so I don't think this is me running into a corner case. JDK 16 has only been release 2 months ago, and the rules have changed quite a bit since JDK 15, so that's not an old problem, it's a new one. I think adding the --illegal-access=permit option on the command is sufficient to solve all those problems, but the problem is still the same : this option will break if using JDK 1.8. This has to be configured on the project and not globally. I'm not sure what you refer to with the setenv.sh script ? is that something that maven launcher runs prior to launching the JVM ? Le mer. 16 juin 2021 à 09:55, Romain Manni-Bucau a écrit : > Le mer. 16 juin 2021 à 08:39, Guillaume Nodet a écrit > : > > > Well, my point was not really to find a workaround, but rather to start a > > discussion around "maven jvm customization from files is not well > > supported for now" ... :-) > > > > Got it, but point is "is it that often needed"? > Most plugin using toolchain or equivalent can have JVM customization > (already) and it is trivial to handle per jvm config through profiles. > So at the end it is only about maven "embedded" plugins and maven itself. > Last one shouldnt need anything and first ones are solved by forcing a JVM > version for the main build (which does not prevent to run tests and graalvm > native-image with 50 different JVMs). > > The setenv.sh/bat option seems like an acceptable compromise for these > border cases but not sure we need anything more fancy. > What I would be really against is a jvm.config like solution which does not > enable to use any configuration (we can't use space for example right now > in system properties so if we get the same limitation for env vars it would > be pointless IMHO). > > Hope it makes sense. > > > > > > Le mer. 16 juin 2021 à 07:24, Romain Manni-Bucau > a > > écrit : > > > > > Le mar. 15 juin 2021 à 23:39, Guillaume Nodet a > > écrit > > > : > > > > > > > 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. > > > > > > > > > > Guess the most trivial workaround is to replace the plugin by a custom > > exec > > > one propagating maven current context in an extension and forking the > > > plugin run since maven jvm customization from files is not well > supported > > > for now or would need some more advanced script which could source an > > > optional setenv to set maven_opts but this last one would test java > > version > > > which is never great to launch a build and would require to test args > > "the > > > maven way" (phase, plugin:goal, plugin:goal@exec) to bypass it when > > > possible. > > > > > > > > > > Le mar. 15 juin 2021 à 19:04, Robert Scholte > 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 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 >
Re: Supporting building with incompatible JDK versions on a single project
Le mer. 16 juin 2021 à 08:39, Guillaume Nodet a écrit : > Well, my point was not really to find a workaround, but rather to start a > discussion around "maven jvm customization from files is not well > supported for now" ... :-) > Got it, but point is "is it that often needed"? Most plugin using toolchain or equivalent can have JVM customization (already) and it is trivial to handle per jvm config through profiles. So at the end it is only about maven "embedded" plugins and maven itself. Last one shouldnt need anything and first ones are solved by forcing a JVM version for the main build (which does not prevent to run tests and graalvm native-image with 50 different JVMs). The setenv.sh/bat option seems like an acceptable compromise for these border cases but not sure we need anything more fancy. What I would be really against is a jvm.config like solution which does not enable to use any configuration (we can't use space for example right now in system properties so if we get the same limitation for env vars it would be pointless IMHO). Hope it makes sense. > > Le mer. 16 juin 2021 à 07:24, Romain Manni-Bucau a > écrit : > > > Le mar. 15 juin 2021 à 23:39, Guillaume Nodet a > écrit > > : > > > > > 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. > > > > > > > Guess the most trivial workaround is to replace the plugin by a custom > exec > > one propagating maven current context in an extension and forking the > > plugin run since maven jvm customization from files is not well supported > > for now or would need some more advanced script which could source an > > optional setenv to set maven_opts but this last one would test java > version > > which is never great to launch a build and would require to test args > "the > > maven way" (phase, plugin:goal, plugin:goal@exec) to bypass it when > > possible. > > > > > > > Le mar. 15 juin 2021 à 19:04, Robert Scholte 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 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 > > > > > > > > -- > > Guillaume Nodet >
Re: Supporting building with incompatible JDK versions on a single project
Well, my point was not really to find a workaround, but rather to start a discussion around "maven jvm customization from files is not well supported for now" ... :-) Le mer. 16 juin 2021 à 07:24, Romain Manni-Bucau a écrit : > Le mar. 15 juin 2021 à 23:39, Guillaume Nodet a écrit > : > > > 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. > > > > Guess the most trivial workaround is to replace the plugin by a custom exec > one propagating maven current context in an extension and forking the > plugin run since maven jvm customization from files is not well supported > for now or would need some more advanced script which could source an > optional setenv to set maven_opts but this last one would test java version > which is never great to launch a build and would require to test args "the > maven way" (phase, plugin:goal, plugin:goal@exec) to bypass it when > possible. > > > > Le mar. 15 juin 2021 à 19:04, Robert Scholte 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 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 > > > -- Guillaume Nodet
Re: Supporting building with incompatible JDK versions on a single project
Le mar. 15 juin 2021 à 23:39, Guillaume Nodet a écrit : > 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. > Guess the most trivial workaround is to replace the plugin by a custom exec one propagating maven current context in an extension and forking the plugin run since maven jvm customization from files is not well supported for now or would need some more advanced script which could source an optional setenv to set maven_opts but this last one would test java version which is never great to launch a build and would require to test args "the maven way" (phase, plugin:goal, plugin:goal@exec) to bypass it when possible. > Le mar. 15 juin 2021 à 19:04, Robert Scholte 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 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 >
Re: Supporting building with incompatible JDK versions on a single project
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 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 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
Re: Supporting building with incompatible JDK versions on a single project
Hi, There are two levels for me: 1. Maven itself -> maven opts works not bad but we should work ootb 2. Forks -> each plugin must support that and it cna be made dynamic with an extension which autoadjust the conf block Wdyt? Le mar. 15 juin 2021 à 22:02, Benjamin Marwell a écrit : > Hi Tamás, > > So hazelcast runs in the module path. Maven used the class path only. Thus, > add-opens does not do anything. > > UNLESS... you start sub pocesses from Maven, eg using the exec plugin. > > This means we still need an example where you have this issue with Maven. > > On Tue, 15 Jun 2021, 20:27 Tamás Cservenák, wrote: > > > Or xstream for that matter... > > > > ToP > > > > On Tue, Jun 15, 2021, 20:26 Tamás Cservenák wrote: > > > > > 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 > > 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, > > 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 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 > > >> > > > > >> > > > >> > > > > > >
Re: Supporting building with incompatible JDK versions on a single project
Hi Tamás, So hazelcast runs in the module path. Maven used the class path only. Thus, add-opens does not do anything. UNLESS... you start sub pocesses from Maven, eg using the exec plugin. This means we still need an example where you have this issue with Maven. On Tue, 15 Jun 2021, 20:27 Tamás Cservenák, wrote: > Or xstream for that matter... > > ToP > > On Tue, Jun 15, 2021, 20:26 Tamás Cservenák wrote: > > > 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 > 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, > 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 > >> > 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 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 > >> > > > >> > > >> > > >
Re: Supporting building with incompatible JDK versions on a single project
Or xstream for that matter... ToP On Tue, Jun 15, 2021, 20:26 Tamás Cservenák wrote: > 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 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, 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 >> > 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 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 >> > > >> > >> >
Re: Supporting building with incompatible JDK versions on a single project
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 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, 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 > > 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 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 > > > > > >
Re: Supporting building with incompatible JDK versions on a single project
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, 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 > 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 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 > > >
Re: Supporting building with incompatible JDK versions on a single project
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 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 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 >
Re: Supporting building with incompatible JDK versions on a single project
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 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
Supporting building with incompatible JDK versions on a single project
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