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.

Having just implemented a plugin solution using it I can safely say that in the past 20+ years of software development it is the most awful technology I've ever seen. The complexity and over engineering is simply breath taking. It is worse than EJB 1.0, worse than the crazy abuses I have seen with Spring and DI, worse than than dark days of J2EE.

I have lost a lot of respect for Red Hat and IBM after this.

Let's hope the JDK doesn't adopt such wrongheaded approaches, and figures out a sensible way to implement modules. If they can't, then I'd be happy with the current state of third party opt-in approaches instead.

Simplicity -> usability && maintainability && security && popularity

"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?

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.

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.

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

https://jcp.org/en/jsr/detail?id=294

http://javaposse.com/java_posse_259_jigsaw_and_jsr_294_inter...

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”

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.

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

But I believe you could order a VHS casette (possibly for free) with the informational video long before infomercials became a thing. They just had one ready to go before anybody else.

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

Disclaimer: These are my views, not my employers, I'm not involved in the JPMS work.

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?

Yes, this will cause some issues initially but I have hunk it's a good move for Java in the long term.

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.

For instance, Leinigen putting itself on the boot classpath to get faster startup time is really a hack to work around the problem that Clojure apps do way too much stuff at startup and generates very old bytecode forms that takes a lot of work to verify. If you want to disable bytecode verification for Clojure apps you could just use -verify:none instead of blaming Java 9 for changing the way things are loaded at startup, which has never been a guaranteed property of the platform.

Lots of complex apps and language runtimes have been making assumptions about things that were never guaranteed or even documented and will need adjustment in Java 9, but that's OK - the prior situation was never sustainable and a big part of why Java 9 is taking so long and is such a big effort is to get the ecosystem onto a more sustainable, supported footing. Creating supported replacements for Unsafe stuff is one such example but there are plenty of others.

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.

Curious, how does jigsaw make things awful for clojure?

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

It's pretty strange that just because Clojure uses SQL's Timestamp (why ?) that it should be a default.

Clojure uses it because it's the only sane time instance in the stdlib. It is not an uncommon class to use for that reason; the underlying reason is that j.u.Date sucks.

Just curious, why haven't they switched to java.time.LocalDateTime? Java 8 has been out for 3 years now.

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.

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.

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?

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.

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.