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

Alex Buckley alex.buckley at
Fri Dec 4 01:03:53 UTC 2015

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 and recompile it and catch these 
issues up front, than modify MANIFEST.MF and run the main module and 
hope the tests catch them.


More information about the jigsaw-dev mailing list