not module aware

Alan Bateman Alan.Bateman at
Tue Mar 7 09:06:35 UTC 2017

On 07/03/2017 08:32, Volker Simonis wrote:

> Hi,
> 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.


More information about the jigsaw-dev mailing list