Capsules don't start with Java 9

[mikehearn]

Capsules use JMX internal APIs as part of their startup sequence, which fails on Java 9. It wasn't clear to me from a 30 second glance at the code what exactly Capsule is doing with JMX. The docs don't mention any interactions with it.

I suggest one of the following:

• Port to Java 9 APIs, if there are any that can replace the use of internal API usage.
• If there aren't, flag this to the Java team and ask for the right APIs to be provided. Then either:
  1. Drop the relevant feature
  2. Add the magic metadata files to the JARs to forcibly open up the internal APIs to Capsule, which I believe Jigsaw does allow.

[pron]

Capsule tunnels JMX from the application to the capsule process. For the record, the unsafe bits are this, and this, which uses a hidden API to programmatically start a JMX server that doesn't prevent the application from shutting down.

[mikehearn]

Ah, Capsule runs a sub-jvm? Perhaps it's not a big deal - I think JMX is mostly used these days with custom agents to export the data anyway. I bet it could be done via reflection and just dropped on Java 9 for now.

[pron]

Ah, Capsule runs a sub-jvm?

Yes, when not trampolining with a "real executable capsule". After all, Capsule must configure the application's JVM. When trampolining, the app's JVM is replaced by the app's using exec.

I bet it could be done via reflection and just dropped on Java 9 for now.

I'll try using VirtualMachine.start[Local]ManagementAgent (added in JDK 8) for JDK8 and up. I'm assuming the problem is with the sun.management.Agent class, which has been removed (I think) in JDK 9.

[mikehearn]

It's actually this one:

CAPSULE EXCEPTION: class Capsule (in unnamed module @0x4f9a3314) cannot access class com.sun.jmx.mbeanserver.JmxMBeanServer (in module java.management) because module java.management does not export com.sun.jmx.mbeanserver to unnamed module @0x4f9a3314 (for stack trace, run with -Dcapsule.log=verbose)

[pron]

Oh, that may be an even easier fix, but I'll need to learn more about the module system's rules re reflection. Do you have a link for info about the module system (I've never tried it)?

[mikehearn]

It's "complicated" :(

The place to start reading is here: http://openjdk.java.net/projects/jigsaw

The JEP that's relevant to users of internal APIs is here: http://openjdk.java.net/jeps/260

By default, the module system also blocks reflection at runtime into internal APIs. Modules can opt in to having compile time but not runtime encapsulation, but I don't think the JDK modules do this.

There are a variety of back doors. One is a command line flag that forcibly exports things from a module i.e. de-encapsulates them. As Capsule controls the JVM command line flags, that is probably the simplest fix, if there isn't a cleaner way to do it.

It sounds like this is really just a workaround for a bug/missing feature in the JDK itself though. Shouldn't the JMX server be a daemon thread? Perhaps the best fix is to get the underlying problem resolved in time for Java 9 so the internal accesses are no longer needed.

[pron]

Oh, the daemon problem, currently handled by the Agent class, has a solution in JDK 8/9. But the problem you mention is different. It requires reflection in the capsule's JVM (over which capsule has no control) to tell the management system to use a proxy MBeanServer (the one connected to the app) instead of the local one. This feature will probably need to be changed when running on 9.

In the meantime I'll just log the error and ignore it.

[mikehearn]

OK. It's a java.lang.IllegalAccessError

[pron]

The SNAPSHOT version should now run on JDK 9 (without JMX tunneling)

[holgerbrandl]

What the planned release date of a version including this jdk9 compatibility fix?