thanks for the praise, I appreciate it. Point by point:
- Mark Reinhold clearly stated that he does not want to expose those internals, because (a) they have to be maintained and (b) they make implementation more complex because the assumption that they are only called in a specific phase would turn out to be wrong, requiring further changes (his assessment, not mine).
- SAP says “two main concerns exists (i.e., automatic modules, reflection) that potentially conflict with an easy adoption of this JSR”, which makes it sound like reflection got too complicated. I doubt this is going to change.
- Deactivating (maybe optionally) the check for dependency cycles is surely a simple thing.
- The proposed fixes seem simple enough but are apparently not uncontroversial.
Regarding these points, but particularly the latter two, my main argument is that while changes might make sense I see little chance that the Jigsaw team is going to implement them in the 30-day time frame. These are important design decisions that have far reaching effects and need to be maintained “forever”. Whether the implementation is simple is beside the point.
Regarding my own opinion on them: I can not really comment on the importance of the primitives and while skeptical that module isolation is that simple, would like to see support for it. But I don’t see why that has to happen now. Why not release JPMS the way it is and work on those other features in due time?
Finally, yes, I also thought that having JPMS as an implementation detail might very well be the result if the JSR is shut down.