The critical missing pieces and a path forward

[David M. Lloyd]

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