module-info.java just causes problems

[Alan Bateman]

On 11/05/2016 13:52, David M. Lloyd wrote:
>
> In practice this happens a lot.  A module's dependency graph depends 
> just as much on the environment as it depends on the classes in the 
> module (if not more so).  Modules are merged and split, replaced with 
> compatibility stubs, renamed, etc.  If you have to recompile every 
> module for every environment, a lot of the benefit of modularity and 
> compatibility-by-ABI is lost; changes to a module in an environment 
> would lead to a massive cascade of recompilation.
The module system can support many refactoring scenarios, including 
merging and splitting. I can see myself refactoring modules that I 
maintain, I'm less sure that I want to refactor modules coming from 
other projects. If I found myself refactoring modules from elsewhere 
then I would expect to have to build and test those modules, it would be 
strange not to do and I don't understand how you can get away with this 
when changing code in those modules. It might be useful if you could lay 
out a specific scenario as it may be that we are talking completely 
different things.

-Alan.