Hacker News Reader

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

What is the common case Jigsaw solves? It doesn't deal with dependency versioning.

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.

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?

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.

Anyone who believes OSGi is good is either (a) deluded or (b) ignorant.

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.

I've been working on an OSGi platform for the last 6 years, and I can't agree with this more.

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.

Damn straight. XML DI config files overwhelm end-users (and developers) with a metric crap container port of details and things to break in non-obvious, diffusely (un)documented ways. (See also: configuring Atlassian on-prem products)

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

Worse that CORBA?

What has J2EE/Java EE been replaced with?

No single thing, rather it's been displaced by using specific targeted libraries instead of enormous frameworks.

Ah, thanks very much for your reply.

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

After 10 years, why couldn't it be made unambiguous to everyone involved?

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

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

Politics, as it isn't a clone of OSGi.

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.

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

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.

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

I was thinking of their competitor... mighty something?

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.

Why would you think that this has anything to do with IBM's consulting arm and not the fact that IBM maintains their own JVM and employ a ton of JVM experts to develop and maintain it. Jigsaw was a great idea but poor in execution. I feel for the people who put their effort into it and hope that some of the work can be salvaged for the future, but this is one of the cases where it's not worth it to rush through an incomplete solution.

How is it incomplete? It's declaredly small scope, and it meets that goal pretty well.

That may be true; but it's reasonable to be against Jigsaw even if you don't want Jigsaw to be a meta-module system.

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

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.

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?

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

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.

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.

It sounds a lot like the issues Clojure has with Java 9 are to do with rather non-obvious assumptions it made about how the JVM works that are now broken.

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.

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

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.

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

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.

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

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.

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.

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.

If the Reflection and SQL libraries are opt in then why doesn't Clojure just mandate that if you want their software to run you need to enable these modules ?

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

That would necessarily move it off the bootclassloader, for one.

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.

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

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

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

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

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.