> On Mar 8, 2017, at 2:48 AM, Alan Bateman <alan.bate...@oracle.com> wrote: > > 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.
I agree with Alan that it isn’t right for the management interface to expose ModuleFinder. I think it may be useful to monitor what modules are loaded probably with its metadata and location. This requires further investigation to determine what metrics and operations to be exposed. This would probably be JDK 10. Mandy
