Got it. Thanks! The problem with JMXConnectorServer is that it keeps the JVM running with a non-daemon thread -- that's the only reason why I use sun.management.Agent. Perhaps it would be a good idea to provide a solution for that, but this is the wrong mailing list for that discussion...
Ron On Fri, Jul 24, 2015 at 2:22 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > On 24/07/2015 10:12, Ron Pressler wrote: > >> OK, but assuming I have no control over the user's runtime image, am I >> correct that programmatically starting the local JMX agent as I do now >> (without the Attach API) will no longer be possible in Java 9? >> >> I'm not aware of any supported way of doing this in any JDK release, at > least not without using Runtime.exec or ProcessBuilder to invoke the jcmd > tool which might or might not be present. > > If you have code making direct use of JDK-internal classes such as > sun.management.Agent then it fail at both compile-time and run-time with > JDK 9 once the module system goes in. There will be a command-line option > to work around this but no guarantees of course as sun.management.Agent > might not exist, might be refactored significantly, etc. > > You probably know this already but you can start your own > JMXConnectorServer if you want. Also you don't need the JMX agent to access > the platform MXBeans in the current runtime. > > As regards tools using the attach API then then moving them to modules > means they can have an explicit dependency on the jdk.attach module. This > is good because it means they won't even start on a run-time that doesn't > the jdk.attach module. Also if you get to create your own run-time image > and want to include one or these tools then it will ensure that the > jdk.attach module is also linked in. > > -Alan >
