not module aware

Alan Bateman Alan.Bateman at
Wed Mar 8 10:48:33 UTC 2017

On 08/03/2017 10:22, Volker Simonis wrote:

> :
> 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?
I don't think exposing the ModuleFinder is right, esp. when you think 
about a management tool that is accessing the managed VM over a network 
connection (meaning not local). In your previous mail then you mentioned 
the sun.boot.class.path property but that is only useful for 
informational purposes when the management tool is on a different 
system. So I think it requires stepping back and seeing what might be 
useful to expose in a platform MXBean. We rev'ed the debugger APIs to 
allow a debugger to enumerate all loaded modules and something along 
those lines might be useful for RuntimeMXBean. On the other hand, 
ClassLoadingMXBean only exposes the count of classes loaded and 
unloaded, it doesn't provide a way to enumerate the loaded classes. 
Summary information and counts is typical of the metrics that are 
exposed by the platform MXBeans. So I think further analysis is needed 
to see what make sense here.


More information about the jigsaw-dev mailing list