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

[mark.reinhold at oracle.com]

2015/2/26 1:11 -0800, Tim Boudreau <niftiness at gmail.com>:
> 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.

It's true that an application is a module that depends, either directly
or indirectly, upon all the other modules that make up the application.

I don't see how it makes sense, however, to conceive of "framework" or
bootstrap code as depending upon all the other modules in an application,
and to limit that code's ability to manipulate modules.  Such code will
have to interact with the module system, and maybe even inspect module
artifacts and do some reflection, in order to set things up on behalf
of the application itself.  In what way is that a problem?  Or am I
misunderstanding something?

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

The goal is even stronger: To make such classes inaccessible, not merely
invisible.

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

Yes, and they can already use JVM TI to get that information.

- Mark