I don't think it breaks hardly anything except for those using many deprecated or internal items anyways. And if there are BC incompat concerns, they should be addressed specifically but they don't seem to be the primary reasons for "no". Sure we can agree that Jigsaw is not necessarily required for JVM modularization. But surely we could also agree that dogfooding a feature available to all is much better than an internal-only set of jmod files with their own internal-only way of being used. We all want the benefits of modularity especially wrt access restrictions across modules.

Reflection to sidestep visibility wasn't deprecated, and the bootclassloader's properties weren't internal AFAICT; both of those broke Clojure pretty heavily.

I'm not sure we can agree that the dogfooding is preferable. The penalty paid in the stdlib would have to be paid time and time again by users -- as it stands, Jigsaw is not something I can conveniently opt-in (or opt-out) -- it's very clear that the opt-out switches are temporary hacks, and even those don't make porting trivial. As someone who used to be very active in the Python community, I think the 2/3 comparison is very apt.

The problem with that is that nobody is backporting fancy compiler improvements to JDK8; I can't get my faster JDK without also buying into a module system I didn't want and also broke my code.

It is certainly not clear to me that stronger visibility restrictions are a priori desirable when they break dynamic hosted languages. Reflection as a side-stepping mechanism is already easy to detect and clearly opt-in by the reflector, and you've had the option of opting out for ages with Security Managers. All Jigsaw buys you is another level of granularity in that visibility (not just class, subclass, package) and breaking the workarounds for when you actually really mean it.

> Can we agree that making JVMs smaller does not necessarily require Jigsaw, its JSP, or in fact anything that can meaningfully be described as a module system? Do we agree that splitting up the stdlib can have size and performance benefits without having to break the stuff Jigsaw breaks?

I don't think we can unless there's an implementation proposal that takes that approach?

Certainly I think it would be impractical to make the JVM smaller without having visibility restrictions that apply even to reflective access. To be able to develop applications/library intended to run against a smaller JVM I need a way to restrict myself from using certain features even when developing on a full-sized JVM.