Module, Class, and Resource Iteration (Was: Re: Module-system requirements)

[mark.reinhold at oracle.com]

2015/2/25 11:01 -0800, david.lloyd at redhat.com:
> One thing that is missing from the requirements is the ability to 
> iterate or enumerate modules, classes, and/or resources.  This is one 
> capability that people seem to be assuming will be magically provided by 
> a module solution.
> 
> While it seems to me that resource or resource directory iteration is 
> (modulo the discussion on the "Exporting things" sub-thread) easily 
> accomplished, defining the meaning of module iteration and class 
> iteration is a little bit more involved.

Yes ...

> To iterate modules implies that the configuration has a complete picture 
> of all the modules it can load, and that it can iterate over this 
> picture in a relatively inexpensive manner.  This is probably 
> reasonable, though in my imagination I see that the set of available 
> modules may change over time within the life of a single VM process.

It should be straightforward to iterate through the modules already
present in a configuration.  Iterating through the modules available
when creating a new configuration, or extending an existing one, should
be possible but might not be very efficient since it will most likely
require walking the filesystem.

Do we need a requirement to capture this?  It seems pretty low-level.

> Iterating classes is a stranger expectation though, because while it is 
> a reasonable inclination to want to try this, it is possibly actively 
> harmful to start loading previously-unloaded classes.  So such a 
> function would either need to restrict its output set to loaded classes, 
> or do something else like just enumerate class names.  In addition, 
> there are security considerations to take into account; a caller should 
> only "see" classes that are accessible to it (though things like 
> frameworks may need an elevated capability in order to introspect 
> non-public classes).

It wouldn't be hard to iterate through the class files in a module
artifact.  Iterating through the set of classes already loaded for a
module (or by class loader) is possible but trickier.  JVM TI already
supports this [1]; does it need to be possible in a direct reflective
API?  Are there use cases which require that?

> Another potentially iterable "thing" is packages, either in the form of 
> names or Package objects.  No comment on the applicability or lack 
> thereof of such a capability though.

Again, are there use cases for this kind of query?

- Mark


[1] http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#class