java.lang.management.RuntimeMXBean not module aware

[Volker Simonis]

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:
>>
>> 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