On 07/03/2017 08:32, Volker Simonis 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.
Fair point although many of the existing methods are just convenience
methods (they are equivalent to invoking System.getProperty).
RuntimeMXBean also defines getSystemProperties to get all the system
properties and so a management tool does have a way to get the module
path, upgrade module path, and main module/main class if needed.
RuntimeMXBean also defines getInputArguments so there is a way (where
supported) to see VM options such as --limit-options.
That said, I could see one of the platform MXBeans (maybe RuntimeMXBean)
exposing access to the modules in the runtime. It's an area that was
looked at briefly in the early exploratory phase of Project Jigsaw but
not in recent time.
-Alan.
