is ClassLoader.loadClass() supposed to work on module-info classes?

[Alex Buckley]

On 12/3/2015 4:47 AM, David M. Lloyd wrote:
> On 12/02/2015 04:49 PM, Alex Buckley wrote:
>> Now we reach the disagreement. We don't think the module declaration
>> will be as fluid as you do. Yes, frameworks and other tools will want to
>> modify module declarations (usually by addition of dependencies or
>> exports) but that's a handful of actors, all of whom are perfectly
>> capable of using ASM. 99.99% of humans have no business modifying
>> someone else's module declaration by hand, so there is no reason for it
>> to be easy.
>
> I am baffled as to the basis for this assertion.  This kind of change in
> fact happens (present tense) frequently - very frequently if you have
> any kind of system for updates.  Modules get split or merged,
> implementations from one vendor get swapped out for another, multiple
> versions of things are introduced.  I honestly can say that I do not
> understand how the Jigsaw team arrives at this kind of conclusion with
> literally zero production experience!

If you're splitting or merging modules -- especially someone else's! -- 
then you need to let the compiler check that the newly factored modules 
are well-formed: they export packages that they actually contain, and 
they don't read anything that would lead to a split package. (The 
constraints in j.l.m.Configuration::resolve, basically.)

Similarly, if you're changing a module to require a module by Vendor X 
rather than Vendor Y, then you'll want the compiler to check that your 
module isn't led by Vendor X's module to read anything that would lead 
to a split package.

Better to modify module-info.java and recompile it and catch these 
issues up front, than modify MANIFEST.MF and run the main module and 
hope the tests catch them.

Alex