The critical missing pieces and a path forward

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