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

[Alan Bateman]

On 04/12/2015 12:59, David M. Lloyd wrote:
>
> 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?

FWIW, I also read your original mail as the wild west as it came across 
as arbitrary refactoring of other people's modules. So best to make 
things as clear as possible as it's just too easy to get into confusing 
discussions here.

As regards refactoring then the current design supports many cases of 
merging and splitting, something for another thread I think.

-Alan.