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

[David M. Lloyd]

On 12/03/2015 07:03 PM, Alex Buckley wrote:
> 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.)

So you're saying that if I have C depending on A, then update A or I 
split A and B in my distribution, I need to recompile C?  I don't think 
that's a realistic proposition.  Do I then have to recompile things that 
depend on C?  Or things that depend on those things?  How would updates 
work in such a scenario?  Do I need to put the dependency versions of 
every dependency in my version string so that I can tell the difference 
between C compiled with the original A versus C compiled with the new A/B?

It should not be necessary (and indeed it is not necessary today) to do 
this kind of cascading recompilation; I don't think that is something 
reasonable to ask of users.  If they have to recompile such large 
swathes of their project any time anything has changed, the point of 
modules has been at least partially defeated.

Java has a fairly clear ABI contract; a better approach would be for 
users to know if they've changed compatibility when they compile A, or 
when they split A into A and B, etc.  If the ABI is the same or is 
forwards-compatible (i.e. only adding members), then why would a user 
want to recompile everything else?  Is this not a red flag that the 
encapsulation rules are unrealistic?

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

-- 
- DML