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.ll...@redhat.com
<mailto:david.ll...@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
