module-info.java just causes problems

[Paul Benedict]

Why can't the layer assist specifying the Module Configuration to each
module in the Module system? By that I mean that the module-info.class
shouldn't be read and accepted without mediation. The Layer should get the
chance to augment (add, change, remove) anything it wants. Now perhaps the
default behavior is to blindly accept module-info.class, but in an EE
world, I say this is insufficient. The container should be able to do
whatever it wants to the module information before it gets applied by the
JDK.

Cheers,
Paul

On Thu, May 12, 2016 at 6:46 AM, David M. Lloyd <david.lloyd at redhat.com>
wrote:

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