> > On Mar 7, 2017, at 12:32 AM, Volker Simonis <volker.simo...@gmail.com> wrote: > > Hi, > > java.lang.management.RuntimeMXBean offers methods like getClassPath(), > getLibraryPath() and even getBootClassPath() if > isBootClassPathSupported() returns true. While > isBootClassPathSupported() has been changed in jdk9 to always return > false (although the VM still supports -Xbootclasspath/a) no additional > methods have been added to RuntimeMXBean to query the new module path. > > Is this intentional? I think RuntimeMXBean should contain at least a > new method getModulePath() wich returns the VMs module path. Looking > at the latest spec [1] I couldn't find such an addition. Will this be > added in the final version or are there some reasons against having > getModulePath() in RuntimeMXBean? > > Exposing further information trough RuntimeMXBean like the one > provided by the --upgrade-module-path, --add-modules, --limit-modules, > --list-modules could be interesting/useful as well. >
I file https://bugs.openjdk.java.net/browse/JDK-8176314 to track this and I agree that certain modular runtime information such as the module graph would be useful for a management tool to monitor. As Alan mentions, RuntimeMXBean::getInputArguments and getSystemProperties could be used to get the module path, upgrade module path, etc in the time being. Mandy
