NoClassDefFoundError: Could not initialize,class com.google.inject.internal.cglib.core.$ReflectUtils

[Alan Bateman]

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