module-info.java just causes problems

[David M. Lloyd]

This is along the lines of what I've requested.  Still waiting for any 
kind of feedback though.

On 05/12/2016 11:19 AM, Paul Benedict wrote:
> 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
> <mailto: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
>
>

-- 
- DML