4 ms·

So, the final calculus is if the cost of having Jigsaw warrants the benefits that Jigsaw does provide. For me, the answer is clearly no. "Modularity" is a word

by lvh 9y ago

So, the final calculus is if the cost of having Jigsaw warrants the benefits that Jigsaw does provide. For me, the answer is clearly no. "Modularity" is a word with a lot of meanings, and we're going to need to pin one down to discuss it meaningfully -- especially since competing module systems solve a different set of problems. To me, modularity is about isolation, and being able to run a lot of stuff together on a JVM that you previously couldn't; say because of incompatible versions of Guava or whatever. To you, it might mean "increased visibility restrictions". (I'm not arguing for one definition or another; just that we should probably agree on one.) 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?

kodablah 9y ago
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.
- lvh 9y ago
  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.
lmm 9y ago
> 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.

by lvh 9y ago

kodablah 9y ago

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.

lvh 9y ago
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.

lmm 9y ago

> 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.