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

[David M. Lloyd]

On 03/09/2015 04:04 PM, mark.reinhold at oracle.com wrote:
> 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.

Probably not, I guess, unless someone very feels strongly about having 
this ability specified.  Internally we created an API method to allow 
both kinds of iteration on hints that certain parties may be requesting 
this functionality, but it remains unimplemented for all of our module 
loader types leading me to believe that it might not have a real 
practical application (that isn't better solved in another way).

>> 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?

For resources, definitely; for classes, none that I'm aware of.  We 
support only resource iteration, though one could extrapolate the set of 
available classes from that given our simple relationship between those 
two things.

>> 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?

None that I know of.  We don't support it at present.
-- 
- DML