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

[Tim Boudreau]

On Wed, Feb 25, 2015 at 2:01 PM, David M. Lloyd <david.lloyd at redhat.com>
wrote:

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

Should a module be able to iterate modules it does not depend on (or not in
the transitive closure of its dependencies) and could not load?

Or is "framework" or bootstrap code logically a module which depends on all
other modules in the application?

I know that's a very abstract sounding question, but it's cleaner to have a
world where it's modules all the way down, than a special "framework code
over here" case.  So if an "application" is effectively a module that
depends, directly or indirectly, on everything else that makes up the
application, the module abstraction is far less leaky.


> 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 prevriously-unloaded classes.


I think part of the goal is to make exploits like [1] impossible (using a
MethodHandle to call into JMX to get it to load an untrusted byte array as
bytecode) by making classes in modules you can't "see" via the closure of
your dependencies *really* not visible from call sites that can't see
them.  That particular exploit was within the JDK, but similar things could
easily be done using modules not part of the JDK if it's possible to get
things to call each other that shouldn't.  It seems desirable for a module
system to provide a better firewall than that.

For the "iterate all classes" thing mentioned earlier, that is typically
used as a nasty hack to accomplish service discovery that can be done with
metadata, and doesn't seem a use case worth encouraging.  Certain things
like profilers and agents might need that, however.

-Tim

[1]
http://timboudreau.com/blog/The_Java_Security_Exploit_in_(Mostly)_Plain_English/read