module-info.java just causes problems

[David M. Lloyd]

On 05/12/2016 02:28 AM, Alan Bateman wrote:
> On 11/05/2016 15:14, David M. Lloyd wrote:
>>
>> 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.
>>
> Thanks for the context. So I'm curious what will happen when you
> download JAR that is a modular JAR where the author have put in the
> effort to declare their dependences and exports, maybe services too. Are
> you going to override that too?

Almost certainly.  At the very least we're going to review it to see if 
the module names match with our environment.  If we retain our current 
modularity system then we'd likely have to externalize the descriptor as 
well, probably manually, and the internal one would be stripped out or 
ignored.  But, that is as yet undecided and may depend on whether and 
how many of our issues get resolved in Jigsaw.

-- 
- DML