java.lang.management.RuntimeMXBean not module aware
volker.simonis at gmail.com
Wed Mar 8 10:22:46 UTC 2017
On Tue, Mar 7, 2017 at 6:56 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
>> On Mar 7, 2017, at 12:32 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
>> 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  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
We could for example add a method getObservableModulesFinder()" to
RuntimeMXBean which returns
The question only is if this is still realistic for Java 9 or if it
has to be postponed to Java 10?
More information about the jigsaw-dev