On 14/01/2016 12:06, David Holmes wrote:
Of course, but I'm having trouble seeing the overall architecture of
the solution or understanding how the problem manifests. Is it just VM
initialization that assumes classes are always present?
I haven't looked at what Dmitry is doing but I think part of it is
startup, say starting with com.sun.management properties on the command
line. In that scenario the VM must have management support (can't be
minimal VM) and the java.management module must be present. At second
part might be using the jcmd tool to run diagnostic options that require
the VM to have the jdk.management module. In both cases then it would be
good to handle them gracefully.
One thing to be aware of is that in the jigsaw/jake forest then we have
changed this code so that attempting to start with com.sun.management
properties set on the command line will add "java.management" to the
initial set of modules to resolve. This means that startup already fails
gracefully when this module is not observable, here's an example:
$ jlink --modulepath jmods --addmods java.base --output myimage
$ myimage/bin/java -listmods
java.base@9-internal
$ myimage/bin/java -Dcom.sun.management.jmxremote.port=5000 -jar foo.jar
Error occurred during initialization of VM
java.lang.module.ResolutionException: Module java.management not found
at
java.lang.module.Resolver.fail(java.base@9-internal/Resolver.java:860)
at
java.lang.module.Resolver.resolve(java.base@9-internal/Resolver.java:291)
at
java.lang.module.Configuration.resolve(java.base@9-internal/Configuration.java:249)
at
jdk.internal.module.ModuleBootstrap.boot(java.base@9-internal/ModuleBootstrap.java:188)
at java.lang.System.initPhase2(java.base@9-internal/System.java:1911)
-Alan
