On Tue, Mar 7, 2017 at 6:56 PM, Mandy Chung <mandy.ch...@oracle.com> wrote: >> >> 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.
Thanks for filing the bug. I think this could be easily achieved by exposing jdk.internal.module.ModuleBootstrap.finder() trough the RuntimeMXBean. We could for example add a method getObservableModulesFinder()" to RuntimeMXBean which returns jdk.internal.module.ModuleBootstrap.finder(). The question only is if this is still realistic for Java 9 or if it has to be postponed to Java 10? Volker > > Mandy
