8 ms·

This is unambiguously a good thing. Jigsaw didn't solve the toughest problems it had hoped to solve, and there are much less impactful ways to accomplish some o

by lvh 9y ago

This is unambiguously a good thing. Jigsaw didn't solve the toughest problems it had hoped to solve, and there are much less impactful ways to accomplish some of these goals. As it stood, Jigsaw broke tons of applications that did non-trivial things with class loaders, reflection or even circular deps. As a consequence, while Jigsaw (after significant effort) might not be disastrous for Java, it's pretty awful for most things that aren't Java that target the JVM, like Clojure. Meanwhile, significant incremental engineering benefits in JDK9 were being held back by this sweeping change; so now maybe we can just get a better JVM without breaking the world. As it stood, Jigsaw required a ton of engineering effort internally and externally and severely broke the backwards compatibility that has made Java such a workhorse of the enterprise. All of that at very questionable benefit to the end user: still no module-level versioning of deps. That doesn't mean this effort is totally wasted: the oldest parts of the stdlib were due for a touch-up. Lord knows that I have my differences with how Red Hat operates sometimes, but I don't think suggesting their vote against Jigsaw is somehow a political plot to benefit OSGi or JBoss modules is reasonable. (FWIW: I also don't think OSGi's and JBoss' alternatives are great, but that's OK, because they're opt-in.) That theory has little explanatory power: why are all of these other companies voting against? Disclaimer: I have no stake in any of the voting parties, but I do write a lot of JVM-targeting software.

dillon 9y ago
Reading some of the "no" comments. Red Hat and IBM both have a list of reasons why they think Jigsaw is not ready. As for the rest of the companies voting "no" it looks like it's mostly because "there is not a consensus amongst the EC". Which might be a fancy way of saying "If Red Hat and IBM don't approve then nor shall I".
- aardvark179 9y ago
  I think that isn't entirely fair. Several are quite careful in their wording ("the spec as submitted", meaning the things that are still being worked on need to be sorted out), and significant progress has been made since the spec was submitted. I doubt the EG will achieve a consensus on all issues, but if I had to guess I'd say it will go through no the second vote. Disclaimer: These are my views, not my employers, I'm not involved in the JPMS work.
slantedview 9y ago
> I don't think suggesting their vote against Jigsaw is somehow a political plot to benefit OSGi RedHat and others clearly do want Jigsaw to be a meta-module system though, which to any sane person who has no financial interest in existing module technologies is ridiculous, and would be exactly the kind of mind-numbing complexity that people hate on Java for. Eclipse's No vote even came with this comment: “The Eclipse Foundations looks forward to a revised specification which will enable independent implementations”
- hinkley 9y ago
  IBM Global Services always seemed to me to hire exclusively people with an exceptionally high tolerance for complexity (aka 'bullshit'). Every encounter I've had with them has been to build the most complex thing that they could keep running. Which is to say, you couldn't pay your people enough money to deal with it so you have to keep IGS around to maintain what they built. People get exasperated with their convolutions and basically say something like, "Look, whatever. Just do what you want and stop updating me on your latest travesty. I don't want to know." And then they win. Every time I see their stuff it reminds me of those all-in-one woodworking machines (It's a drill press AND a lathe!) you used to see on infomercials when infomercials were still a new thing. Too goddamned many moving parts, things that can break, and ways you can lose a finger. Any time I see IBM involved in a JSR, the IGS modus operandi is written all over it.
  - LeifCarrotson 9y ago
    > Every time I see their stuff it reminds me of those all-in-one woodworking machines (It's a drill press AND a lathe!) you used to see on infomercials when infomercials were still a new thing. Too goddamned many moving parts, things that can break, and ways you can lose a finger. You mean a Shopsmith? Those have been around since before infomercials, and they are still producing new versions. They're actually a decent combination wood lathe/horizontal boring drill press (which both already need the fancy variable speed drive), and there's nothing complicated about the disc sander that needs a separate machine. But yeah, the table saw option doesn't feel right...
kodablah 9y ago
> This is unambiguously a good thing. I don't believe it's "unambiguously" a good thing. Many disagree with circular module dependencies (I am one) at least at this initial stage. Statements like "breaking the world" are a loaded way of saying "doesn't fit existing module use cases of all members". I think the current implementation was ripe for release and vendors would have worked with it well. I am also dismayed that a compete implementation can be completed before nixed (regardless of the internal reasons we got this far before turning back).
- lvh 9y ago
  Breaking circular dependencies are one of the least impactful things Jigsaw did compared to classloader and resource loading changes; breaking the world is a comment about all of Jigsaw, not an individual change. I agree that "breaking the world" is not an appropriate description of a JDK9 that breaks circular dependencies; but that's not all what Jigsaw does.
- melling 9y ago
  After 10 years, why couldn't it be made unambiguous to everyone involved? https://jcp.org/en/jsr/detail?id=294 https://jcp.org/en/jsr/detail?id=294 http://javaposse.com/java_posse_259_jigsaw_and_jsr_294_interview http://javaposse.com/java_posse_259_jigsaw_and_jsr_294_inter...
  - pjmlp 9y ago
    Politics, as it isn't a clone of OSGi.
lmm 9y ago
> I don't think suggesting their vote against Jigsaw is somehow a political plot to benefit OSGi or JBoss modules is reasonable. (FWIW: I also don't think OSGi's and JBoss' alternatives are great, but that's OK, because they're opt-in.) That theory has little explanatory power: why are all of these other companies voting against? I think RedHat/IBM are opposing it because it isn't OSGi/JBoss (and whether that's for nefarious reasons or because they genuinely believe OSGi/JBoss are the Right Thing is beside the point), and most of the other opposition is following their lead. I think OSGi/JBoss are failures in the market because they're hideously overengineered, and if Jigsaw is to succeed it should avoid solving most of the problems that OSGi/JBoss claim to. Rather it should solve the common case while being much simpler. The current proposal seemed like a pretty good effort to me.
- lvh 9y ago
  What is the common case Jigsaw solves? It doesn't deal with dependency versioning.
  - kodablah 9y ago
    JVM size restrictability, higher-than-class-level modularity, module-level access restrictions, etc. Your question could be rephrased: "what are the common use cases that componentizing a runtime/stdlib solve?" Not everything is about the module ecosystem, package management, etc. Sometimes componentization has benefits itself without concern for additional features.
    - 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?
dfabulich 9y ago
> Meanwhile, significant incremental engineering benefits in JDK9 were being held back by this sweeping change; so now maybe we can just get a better JVM without breaking the world. I think that was Jigsaw's biggest mistake: trying to build a strict module system that will allow modularizing the JVM and expecting that module system to be useful to Java developers, who are already using powerful userland module systems. I frankly hope that the next iteration of Jigsaw just modularizes the JVM without exposing anything to userland.
- pulse7 9y ago
  This would be one possible step forward. Oracle would gain more time polishing everything and making it backwards compatible and when ready open it for everybody else.
revelation 9y ago
Java needs one module system. At this point, it doesn't matter which. But the continuing fragmentation will be it's death sentence.
- pas 9y ago
  It does matter. Userland modules systems like OSGi can do whatever the fuck they can come up with during an enterprise occult architect-cult seance, but that is not mandatory for everyone else. If the Java Platform does something stupid, you can't just sidestep the garbage and start from scratch.
ledgerdev 9y ago
> it's pretty awful for most things that aren't Java that target the JVM, like Clojure. Curious, how does jigsaw make things awful for clojure?
- lvh 9y ago
  Incomplete list: - As a dynamic language, Clojure uses reflection extensively. Reflection becomes effectively opt-in in Jigsaw-land, breaking tons of Clojure software. - JDK9 breaks dynamic classpath introspection and modification breaking java.classpath, dynapath (and hence CIDER &c). - Clojure itself is no longer loadable from the new bootstrap classloader (clojure.inst requires java.sql.Timestamp). This matters, because being in the bootstrap classloader is a significant performance improvement.
  - desdiv 9y ago
    >clojure.inst requires java.sql.Timestamp Just curious, why haven't they switched to java.time.LocalDateTime? Java 8 has been out for 3 years now.
    - loevborg 9y ago
      Clojure has a fantastic track record of not breaking existing code. Changing clojure's `#inst` to a different class would probably entail such a backward-incompatible change. There are also still people running Java 1.7.
      - timv 9y ago
        The argument put forward here (and elsewhere) seems to be that we want Clojure to gain the advantages of being on the bootstrap classloader in Java 9 while still targeting Java 7 That's pretty unconvincing to me. If you're shipping jars that are intentionally compiled against old JREs then you might not get the benefits of new JVM features. Them's the breaks.
    - MBlume 9y ago
      One of the benefits of Clojure is that it's Just Another JAR. If you want the to use a new version of the Java language, you have to convince your devops people to deploy a new version of the Java runtime, which may take time. If you want to use the latest version of Clojure, all you have to do is change a dependency in your build, and you can use the latest version of Clojure with Java 6 if need be. Maybe eventually compatibility with Java 6 will be abandoned, maybe eventually they'll require 8, but the Clojure devs really don't want to do that lightly.
xg15 9y ago
I don't know. I can kinda understand real-world usage, but this reminds me of the objections when sun.misc.Unsafe was about to be removed. A lot of the "missing features" seem like things that indicate design smells when used and that I would have looked forward to get rid of. Maybe there are projects that have compelling use-cases for circular dependencies, heavy use of reflection or classpath introspection but those features impose a substantial cost on the language with relatively little returns. Why can't they be opt-in?
- lvh 9y ago
  Both sun.misc.Unsafe and the introspection features you cite implement significant functionality that can't really be reproduced any other way. That's fine if all you care about is Java-the-language, but that decision just blew up JRuby, Clojure...
  - aardvark179 9y ago
    Sun.misc.Unsafe is still available and equivalent _safe_ functionality is being introduced before it is removed.and, most reflection stuff can be done public ancestors with a little care. Yes, this will cause some issues initially but I have hunk it's a good move for Java in the long term.
    - lvh 9y ago
      You mention Java again; so I'll mention JRuby and Clojure again. "It will cause some issues" is a serious understatement, and this is a clear violation of the (social) contract the JVM had. Enterprises use Java in no small part because they don't randomly break the billions of lines of Java code out there. s.m.U is a perfect example: they've wanted to break it for a while but aren't doing it until they can actually replace it. A lot more software is broken by Jigsaw than would've been broken if s.m.U went away. Plus: there's an escape hatch: for better or worse, if s.m.U went away, you'd start seeing a whole ton more JNI.
      - mike_hearn 9y ago
pulse7 9y ago
IMHO the best way forward with this is: - take additional time (3-6 months) to work out all current issues without major changes in the module design, then repeat the vote, - in case "No" is voted again: use Java Modules in JDK internally and expose them in one of the later versions when more work is done and community is happy with it.
MarkMc 9y ago
> I also don't think OSGi's and JBoss' alternatives are great, but that's OK, because they're opt-in. I really don't know much about Jigsaw, but I would have assumed it was also opt-in. That is, you can run Java 9 with circular dependencies and Clojure and anything that run on Java 8 - you just have to accept a large, monolithic JRE. Is that true?
- pas 9y ago
  Yes, that's true. By default JAR-s get automatically lifted to fully open modules (that export everything), so everything is reflection-able.
pas 9y ago
> Jigsaw didn't solve the toughest problems it had hoped to solve What was it? As far as I know the JSR had a goal and the proposed JSMP spec is pretty much reaching that and nothing more.

by lvh 9y ago

dillon 9y ago

Reading some of the "no" comments. Red Hat and IBM both have a list of reasons why they think Jigsaw is not ready. As for the rest of the companies voting "no" it looks like it's mostly because "there is not a consensus amongst the EC". Which might be a fancy way of saying "If Red Hat and IBM don't approve then nor shall I".

aardvark179 9y ago
I think that isn't entirely fair. Several are quite careful in their wording ("the spec as submitted", meaning the things that are still being worked on need to be sorted out), and significant progress has been made since the spec was submitted. I doubt the EG will achieve a consensus on all issues, but if I had to guess I'd say it will go through no the second vote. Disclaimer: These are my views, not my employers, I'm not involved in the JPMS work.

slantedview 9y ago

> I don't think suggesting their vote against Jigsaw is somehow a political plot to benefit OSGi RedHat and others clearly do want Jigsaw to be a meta-module system though, which to any sane person who has no financial interest in existing module technologies is ridiculous, and would be exactly the kind of mind-numbing complexity that people hate on Java for. Eclipse's No vote even came with this comment: “The Eclipse Foundations looks forward to a revised specification which will enable independent implementations”

hinkley 9y ago
IBM Global Services always seemed to me to hire exclusively people with an exceptionally high tolerance for complexity (aka 'bullshit'). Every encounter I've had with them has been to build the most complex thing that they could keep running. Which is to say, you couldn't pay your people enough money to deal with it so you have to keep IGS around to maintain what they built. People get exasperated with their convolutions and basically say something like, "Look, whatever. Just do what you want and stop updating me on your latest travesty. I don't want to know." And then they win. Every time I see their stuff it reminds me of those all-in-one woodworking machines (It's a drill press AND a lathe!) you used to see on infomercials when infomercials were still a new thing. Too goddamned many moving parts, things that can break, and ways you can lose a finger. Any time I see IBM involved in a JSR, the IGS modus operandi is written all over it.
- LeifCarrotson 9y ago
  > Every time I see their stuff it reminds me of those all-in-one woodworking machines (It's a drill press AND a lathe!) you used to see on infomercials when infomercials were still a new thing. Too goddamned many moving parts, things that can break, and ways you can lose a finger. You mean a Shopsmith? Those have been around since before infomercials, and they are still producing new versions. They're actually a decent combination wood lathe/horizontal boring drill press (which both already need the fancy variable speed drive), and there's nothing complicated about the disc sander that needs a separate machine. But yeah, the table saw option doesn't feel right...

kodablah 9y ago

> This is unambiguously a good thing. I don't believe it's "unambiguously" a good thing. Many disagree with circular module dependencies (I am one) at least at this initial stage. Statements like "breaking the world" are a loaded way of saying "doesn't fit existing module use cases of all members". I think the current implementation was ripe for release and vendors would have worked with it well. I am also dismayed that a compete implementation can be completed before nixed (regardless of the internal reasons we got this far before turning back).

lvh 9y ago
Breaking circular dependencies are one of the least impactful things Jigsaw did compared to classloader and resource loading changes; breaking the world is a comment about all of Jigsaw, not an individual change. I agree that "breaking the world" is not an appropriate description of a JDK9 that breaks circular dependencies; but that's not all what Jigsaw does.
melling 9y ago
After 10 years, why couldn't it be made unambiguous to everyone involved? https://jcp.org/en/jsr/detail?id=294 https://jcp.org/en/jsr/detail?id=294 http://javaposse.com/java_posse_259_jigsaw_and_jsr_294_interview http://javaposse.com/java_posse_259_jigsaw_and_jsr_294_inter...
- pjmlp 9y ago
  Politics, as it isn't a clone of OSGi.

lmm 9y ago

> I don't think suggesting their vote against Jigsaw is somehow a political plot to benefit OSGi or JBoss modules is reasonable. (FWIW: I also don't think OSGi's and JBoss' alternatives are great, but that's OK, because they're opt-in.) That theory has little explanatory power: why are all of these other companies voting against? I think RedHat/IBM are opposing it because it isn't OSGi/JBoss (and whether that's for nefarious reasons or because they genuinely believe OSGi/JBoss are the Right Thing is beside the point), and most of the other opposition is following their lead. I think OSGi/JBoss are failures in the market because they're hideously overengineered, and if Jigsaw is to succeed it should avoid solving most of the problems that OSGi/JBoss claim to. Rather it should solve the common case while being much simpler. The current proposal seemed like a pretty good effort to me.

lvh 9y ago
What is the common case Jigsaw solves? It doesn't deal with dependency versioning.
- kodablah 9y ago
  JVM size restrictability, higher-than-class-level modularity, module-level access restrictions, etc. Your question could be rephrased: "what are the common use cases that componentizing a runtime/stdlib solve?" Not everything is about the module ecosystem, package management, etc. Sometimes componentization has benefits itself without concern for additional features.
  - 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?

dfabulich 9y ago

> Meanwhile, significant incremental engineering benefits in JDK9 were being held back by this sweeping change; so now maybe we can just get a better JVM without breaking the world. I think that was Jigsaw's biggest mistake: trying to build a strict module system that will allow modularizing the JVM and expecting that module system to be useful to Java developers, who are already using powerful userland module systems. I frankly hope that the next iteration of Jigsaw just modularizes the JVM without exposing anything to userland.

pulse7 9y ago
This would be one possible step forward. Oracle would gain more time polishing everything and making it backwards compatible and when ready open it for everybody else.

revelation 9y ago

Java needs one module system. At this point, it doesn't matter which. But the continuing fragmentation will be it's death sentence.

pas 9y ago
It does matter. Userland modules systems like OSGi can do whatever the fuck they can come up with during an enterprise occult architect-cult seance, but that is not mandatory for everyone else. If the Java Platform does something stupid, you can't just sidestep the garbage and start from scratch.

ledgerdev 9y ago

> it's pretty awful for most things that aren't Java that target the JVM, like Clojure. Curious, how does jigsaw make things awful for clojure?

lvh 9y ago
Incomplete list: - As a dynamic language, Clojure uses reflection extensively. Reflection becomes effectively opt-in in Jigsaw-land, breaking tons of Clojure software. - JDK9 breaks dynamic classpath introspection and modification breaking java.classpath, dynapath (and hence CIDER &c). - Clojure itself is no longer loadable from the new bootstrap classloader (clojure.inst requires java.sql.Timestamp). This matters, because being in the bootstrap classloader is a significant performance improvement.
- desdiv 9y ago
  >clojure.inst requires java.sql.Timestamp Just curious, why haven't they switched to java.time.LocalDateTime? Java 8 has been out for 3 years now.
  - loevborg 9y ago
    Clojure has a fantastic track record of not breaking existing code. Changing clojure's `#inst` to a different class would probably entail such a backward-incompatible change. There are also still people running Java 1.7.
    - timv 9y ago
      The argument put forward here (and elsewhere) seems to be that we want Clojure to gain the advantages of being on the bootstrap classloader in Java 9 while still targeting Java 7 That's pretty unconvincing to me. If you're shipping jars that are intentionally compiled against old JREs then you might not get the benefits of new JVM features. Them's the breaks.
  - MBlume 9y ago
    One of the benefits of Clojure is that it's Just Another JAR. If you want the to use a new version of the Java language, you have to convince your devops people to deploy a new version of the Java runtime, which may take time. If you want to use the latest version of Clojure, all you have to do is change a dependency in your build, and you can use the latest version of Clojure with Java 6 if need be. Maybe eventually compatibility with Java 6 will be abandoned, maybe eventually they'll require 8, but the Clojure devs really don't want to do that lightly.

xg15 9y ago

I don't know. I can kinda understand real-world usage, but this reminds me of the objections when sun.misc.Unsafe was about to be removed. A lot of the "missing features" seem like things that indicate design smells when used and that I would have looked forward to get rid of. Maybe there are projects that have compelling use-cases for circular dependencies, heavy use of reflection or classpath introspection but those features impose a substantial cost on the language with relatively little returns. Why can't they be opt-in?

lvh 9y ago
Both sun.misc.Unsafe and the introspection features you cite implement significant functionality that can't really be reproduced any other way. That's fine if all you care about is Java-the-language, but that decision just blew up JRuby, Clojure...
- aardvark179 9y ago
  Sun.misc.Unsafe is still available and equivalent _safe_ functionality is being introduced before it is removed.and, most reflection stuff can be done public ancestors with a little care. Yes, this will cause some issues initially but I have hunk it's a good move for Java in the long term.
  - lvh 9y ago
    You mention Java again; so I'll mention JRuby and Clojure again. "It will cause some issues" is a serious understatement, and this is a clear violation of the (social) contract the JVM had. Enterprises use Java in no small part because they don't randomly break the billions of lines of Java code out there. s.m.U is a perfect example: they've wanted to break it for a while but aren't doing it until they can actually replace it. A lot more software is broken by Jigsaw than would've been broken if s.m.U went away. Plus: there's an escape hatch: for better or worse, if s.m.U went away, you'd start seeing a whole ton more JNI.
    - mike_hearn 9y ago

pulse7 9y ago

IMHO the best way forward with this is: - take additional time (3-6 months) to work out all current issues without major changes in the module design, then repeat the vote, - in case "No" is voted again: use Java Modules in JDK internally and expose them in one of the later versions when more work is done and community is happy with it.

MarkMc 9y ago

> I also don't think OSGi's and JBoss' alternatives are great, but that's OK, because they're opt-in. I really don't know much about Jigsaw, but I would have assumed it was also opt-in. That is, you can run Java 9 with circular dependencies and Clojure and anything that run on Java 8 - you just have to accept a large, monolithic JRE. Is that true?

pas 9y ago
Yes, that's true. By default JAR-s get automatically lifted to fully open modules (that export everything), so everything is reflection-able.

pas 9y ago

> Jigsaw didn't solve the toughest problems it had hoped to solve What was it? As far as I know the JSR had a goal and the proposed JSMP spec is pretty much reaching that and nothing more.