java.lang.management.RuntimeMXBean not module aware
Alan.Bateman at oracle.com
Tue Mar 7 09:06:35 UTC 2017
On 07/03/2017 08:32, Volker Simonis 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.
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.
More information about the jigsaw-dev