module-info.java just causes problems

[Paul Benedict]

I think the interception would also solve the use case of Redhat's Byteman.
If the Layer can be given access to the Module Configuration and before any
classes in the Module are loaded (chicken-and-egg for module-info.class?),
then class transformation can be accomplished at the same time.

Cheers,
Paul

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

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