is ClassLoader.loadClass() supposed to work on module-info classes?
alex.buckley at oracle.com
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 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.
More information about the jigsaw-dev