module-info.java just causes problems

David M. Lloyd david.lloyd at redhat.com
Wed May 11 14:14:27 UTC 2016


On 05/11/2016 08:15 AM, Alan Bateman wrote:
>
> 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.

We package several hundred JARs in our modular environment today, only 
some of which originate in-house.  The dependency information for these 
modules is established not by the author of these JARs, but by us.  The 
Maven artifact for such a JAR might stipulate certain things, like Log4j 
or a certain version of ASM.  When we distribute that JAR though, we 
don't package the exact artifacts and versions of the dependencies that 
were stipulated in the Maven POM; instead we package single consistent 
versions which are ABI-compatible with all of its dependents, or maybe 
even a completely different artifact that meets the same ABI but 
performs its functions in a different manner.

Over time the environment we distribute evolves, and we split or join 
modules, or we rename old modules to introduce a new major version of 
the same module in parallel, or we replace one implementation with 
another.  When we do this we may chose to deprecate or eliminate a 
module from our environment.  Thus we update all the module descriptors 
that reference the deprecated module, and set new dependencies on them, 
and after a certain amount of time, we delete the old module name.

None of the artifacts that we package are impacted by this process, and 
generally no recompilation is necessary: after all, many of these 
artifacts come directly from Maven or are otherwise built independently 
at an earlier time outside of the context of our target environment. 
It's the ABI that matters; as long as that doesn't change (in an 
incompatible way), recompilation should never be necessary.  I think 
"recompile just to be safe" puts us squarely into "turn it off and on 
again" territory, logically speaking.

-- 
- DML


More information about the jigsaw-dev mailing list