On 19/09/2016 10:01, Dawid Weiss wrote:
Exactly. I reported the problem having the --add-exports-private
option in the back of my mind (saw it in a recent thread somewhere),
but what I'd be more interested in what Rémi asked about.
As a separate note, having multiple non-compatible options becomes
quite a burden to maintain in a complex build. We use shell scripts to
launch (command-line) software, so shell scripts have to detect java
version first and modify options accordingly (currently adding the
missing modules with annotations), maven builds need a separate
profile that adds these options to the compilation (and build), etc.
If you specify -XX:+IgnoreUnrecognizedVMOptions then JDK 8/older will
ignore the JDK 9 options that it doesn't recognize.
Is there any other, more elegant way of doing this that I overlooked?
Pardon the example, but Microsoft's executable manifest files come to
mind -- something that permits attaching "metadata" options to the
program without having to provide it explicitly. Ideally, this
metadata could be conditionally specified for a given JVM version. It
would be interesting to have "java -jar" have such "metadata" in the
manifest.mf file or somewhere else, so that you could specify
JVM-version-specific options there instead of providing them on
command line. Just a thought.
In the main manifest of the main application JAR then you can put:
Add-Exports-Private: java.base/java.lang
and it will be the equivalent of `--add-exports-private
java.base/java.lang=ALL-UNNAMED` on the command-line. Only the main
application JAR can have this attribute (it doesn't make sense for
library JARs of course).
-Alan
