The critical missing pieces and a path forward
David M. Lloyd
david.lloyd at redhat.com
Fri May 5 18:15:47 UTC 2017
Fellow experts,
We and other EC members and community members have, on several
occasions, communicated the various deficiencies we see in the
specification. This is an update to make sure that it is very clear
which few technical, objective criteria are being missed by the current
specification that actually pushes it over the line to unacceptability
to Red Hat in its current form. I can't speak for other EG or EC
members, but I believe this accurately summarizes our position.
The first criterion is to allow cycles to exist among modules at run
time. Our experience with deploying graphs which include third-party
modules leads me to believe that this is going to be real problem that
people encounter, which will be surprising and (in some cases) very
difficult to fix or work around. On the other hand, it should be quite
easy to allow this within the module resolver code, especially given the
self-contained and all-at-once nature of its algorithm.
The second criterion is to re-evaluate (piecewise if necessary) the
(still very small) module primitives patch. This will be a huge boon to
container developers and framework authors (yes, this includes us, as
well as others). This is a very small effort even if the entire patch
is taken (which is something that, as I've said before, we're open to
discussion on, and there is much we can discuss and compromise on, on a
point-by-point basis, if only such discussion could be allowed). This
bridge may open the path to allow the *entire* Java ecosystem to begin
to converge on Jigsaw in ways beyond the class path, and indeed might
mean the difference between unification and fragmentation. Mark himself
has admitted that the specification isn't perfect, which (in my opinion)
also strongly argues in favor of the sensible strategy of providing a
hook for extensibility. This concession could provide relief for _many_
of the other problems that we and others have identified.
The third criterion is to provide package namespace isolation among
module path modules. I maintain that the easiest way to do this is to
isolate each module path module to its own class loader, which also
should greatly ease the transition for existing Java code that uses the
existing ClassLoader API. It is clear to myself and others that package
namespace isolation is a fundamental expectation of a module system; the
few existing widely-deployed module runtimes have this behavior. Our
own experience tells me that this is going to be a real problem for many
nontrivial applications. Not having this type of isolation dramatically
undermines the value of the system.
Our concerns with automatic modules are largely mitigated by the fact
that nobody is *forced* to use them; while I and others continue to
harbor opinions on them, my feeling is that if the current parties of
the discussion can reach a consensus (and it seems close), then that is
satisfactory from our perspective. If the EG reaches a consensus in
this regard then that would be ideal.
We also have a concern that the changes to reflection may still be too
drastic for the community to cope with, and it's possible that this
might still be a deal-breaker for other EC and EG members. I think that
it is a good idea to ensure that there is consensus among the rest of
the EG before we move forward with this as-is.
That's it. After very detailed consideration and discussion of all the
problems we see in the specification - both within Red Hat and with
other individuals outside of Red Hat - these are what we genuinely
believe will hurt the community of Java users the most, and what we can
_realistically_ solve in a short time frame by working together. Most,
if not all, of the numerous other issues that have been identified
should be largely mitigable with the help of these three primary changes.
Mark, please don't consider this to be self-serving. Don't assume that
we or others could only possibly vote "no" out of self-interest, after
we have capitulated on so many other things.
I hope that you can see that we aren't asking for something unreasonable
or impossible. We aren't looking for a "meta" module system. There are
many other things I and others wish could be better about this
specification, but we're not trying to achieve perfection. We're
looking for practical solutions to a few critical problems that push
this over the minimum line for us, and may also solve critical concerns
shared by other EG and EC members. This isn't the end of the road;
let's actually discuss these three things and move forward.
--
- DML
More information about the jpms-spec-experts
mailing list