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.
> 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.
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)
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.
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).
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.
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.
- 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.
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.
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.
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.
> 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?
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.
Hi all, I'm the EC representative for the London Java community (~6000 Java developers, have lots of global outreach programmes etc) - here's our more detailed post on why we voted "No". https://londonjavacommunity.wordpress.com/2017/05/09/explana... - Happy to answer further questions although I've probably found this thread too late :-)
Thanks for the post (you're not too late at all). I do have a couple of questions if you don't mind:
"For our membership, interoperability with the Maven build ecosystem and the ability to build an alternative compiler implementation (i.e. Eclipse’s ejc compiler) is paramount."
Do you believe that package manager interoperability (even if it is the de-facto one) is the responsibility of the JDK? Assuming not, do you believe that Maven would be unable to work with the module system as proposed? If so, why?
Also, and forgive me if I missed it discussed elsewhere, but what is hindering other JVM implementations with the current spec. If anything, I would think one could argue there are too many features for easy independent implementation as opposed to not enough.
Finally, do you believe those two issues warranted a no? If there were an option for "mostly-expecting-couple-of-future-features", would y'all have chosen that?
We believe that that the Java specification for a new module system does need to have an interoperability story with the package management system that Gradle/Maven provides. In particular, the module system needs to be able to bridge/utilise the packages provided by Maven Central (>1 Million IIRC) and allow the Java ecosystem to transition over time. A hard 'break' from the Maven Central world would have meant two separate Java's (a bit like Python 2/3), which for us meant a No vote. These issues are being ironed out, but they weren't at the time of the voting period, so we erred on the side of caution
We think those issues will be resolved, but we'd prefer to see them resolved before voting yes. In particular:
The grammar for the module-info.java with its "restricted keywords" is highly problematic, since the language it defines is not processable by established compiler technology. Hacks are possible, but they are costly and prevent established error recovery techniques from working.
The JCP's mandate is to ensure that competing implementations can be built and at time of spec submission this was very unclear (better now).
Could you elaborate on "not processable by established compiler technology"? The module spec grammar looks like a conventional programming language grammar and javac can apparently process it just fine. Is this an odd way of saying "it doesn't look like Java therefore it can't be integrated with a Java compiler"?
JDK has a pretty clear social contract to not break the world. Of course, they can reneg; but if you gratuitously break stuff like hosted JVM languages and the de-facto package manager, people are going to reconsider your platform.
This is correct and possibly seems crazy from some other language communities :-), but Java is fairly venerable (20 yrs) and is a backbone platform for many risk averse entities and this strong social contract has I believe added to its longevity and relevance.
Ah, yes, specification details and wording/specificity. Always important when supporting independent implementations, but seems a bit pedantic to warrant a complete "no", but as others in their "no" mention, I would expect it to be remedied before the next ballot.
Could you link to the relevant discussion about Maven and AutoNaming? Has that been resolved? (If yes do you think it's a good resolution?) Do you think the goal of JSR is (was?) sane and relevant to the complete java ecosystem? Was it too much or too little?
I think the JSR did over reach itself. Hindsight is a wonderful thing but I think if the scope had been to just modularise Java itself and then have a separate JSR for a user space module system on top of that, it would have worked out better.
I'll prefix this with "I'm not a language design or modularity design expert". I personally would have preferred that JPMS was treated as an internal JVM/API concern. This still would have meant changes for IDE and tools vendors (rt.jar going away required rework for sure) but would have given more flexible options for a user space modular system to be build on top.
An example is that the Module definition file (Module-info.java) is in Java source code. Despite the compile time benefits (performance, security etc) this brings, it really locks down how user level module systems need to interact with this. I personally would have gone for a straight XML/JSON/Manifest.MF/YAML/Whatever format which wasn't tied to the Java compiler so tightly.
Would it be fair to summarize your objection as procedural rather than substantive? Read that as you expect this to pass in its current form with no changes.
No, there are still substantive issues on the table, we just expect that they'll be cleared up in the next 30 days. But since this is so deeply fundamental to the core platform we're only going to vote yes when we're really certain. If it was a library JSR (say a new Collections implementation) then we may have been more lenient.
if it wasn't just policits why did you vote "no"?
Why didn't you reach out to the developers way before the vote, it's unclear to me, since JDK 9 builds were available as early as middle of 2016 and even then, building jdk9 should be possible by somebody with a voting right. Also a lot of stuff was discussed on the development list.
it's not like everything was uploaded a week before the vote.
We have been in close contact with the developers throughout - we're the Java User Group that runs the Adopt a JSR and Adopt OpenJDK programmes that test these things out as early as we're able. The blog post details one of our global hack days for example.
Interesting to see Twitter voting No as well, with the comment "Our main concern is that it is likely that this JSR will prove disruptive to Java developers, while ultimately not providing the benefits that would be expected of such a system".
I opened the second link for the funny title, and its a worthy read.
>Jigsaw has had a multi-year development and feedback period in which the views of other module system creators have been led to substantial design changes again and again. Feedback has been taken from anyone who turned up, even Java nobodies like myself. So given how often Red Hat’s feedback has affected the design of Jigsaw, it seems both petty and wrong to describe it as “cleanroom”, implying it was developed in isolation from the outside world.
>I think we have to cut the Oracle team some slack. They’re attempting to build a module system for the masses, which may entail not supporting out of the box every possible use case that has been put into OSGi or JBoss Modules over the years.
I realize that there are some actual technical questions here but I can't help but be fascinated by the politics of this.
Are IBM and RedHat just against Jigsaw because of commercial interests in JBoss Modules and OSGI? Do they actually care about the technical merits? How can Oracle get to this point in the process without more buy in from the community?
Also I never knew who was part of the EC. Interesting breakdown on who voted for or against.
Will Java 9 go out without Jigsaw? I imagine if they have already modularized the JDK then it's impossible to release Java 9 without Jigsaw.
The biggest concerns are the lack of thought put into build tooling and breakage of existing code. Jigsaw as it is now seems to have been primarily designed to split the JDK up and was pushed into a language-wide module system without enough thought put into the requirements for such functionality.
I don't think anyone is against JPMS solely because they prefer OSGI, etc., but because it can require dramatic changes to the way these systems work (if it can even keep them working at all).
Java 9 will likely ship with Jigsaw in some fashion, at worst it will be limited to the core JRE/JDK libraries themselves.
Given the detail of the post RH put up, and the fact that many companies that aren't RH also voted against, I think the onus is on the claimant to demonstrate that politics are in fact involved. I disagree with a lot of what RH does, have no stake in any voting party, but unambiguously think Jigsaw can not go forward in its current state.
Releasing the JDK9 without Jigsaw enabled is not a major problem.
"I think the onus is on the claimant to demonstrate that politics are in fact involved."
When has there ever been a technical decision made on the technical merits?
It's always politics. Scratch that. It's only politics.
Pieter Hintjens' telling of how RedHat spiked the process around AMQP shows that RedHat is no different from any other player. http://hintjens.com/blog:125#toc15
I had a brief flirtation with a standardization effort. Standards bodies are just another battlefield for belligerents. And I have no problem with that.
By that logic, literally anything Red Hat does is intrinsically bad. I did misspeak: I'll happily believe there is some politics, but that's not what I meant to say; the claim elsewhere is that it's purely or primarily politics.
I've already argued that simply reducing it to "it's politics" is not a reasonable argument unless you can also explain why the RH technical detail post is really just a bunch of politics and not technical arguments, and if you can explain why all of these organizations that don't own a module system _also_ voted against.
Not at all. I'm saying that politics is normal and good. I want RedHat, IBM, Oracle, etc to fight it out. Legally.
--
Before replying, I took a step back, wondering what my position is. Here it is:
This modules effort feels like generics. JDK 1.5 adopted the least objectionable, and therefore least useful, design for generics. The rationalization was "backward compatibility", then and now. The correct answer was to retool the JVM and JDK as needed to do generics properly.
IMHO, Java has leaned too far towards backward compatibility. But what do I know? Java continues to do quite well, despite my objections.
I appreciate it's not the best choice of words, but I'm an ESL, and there is certainly no ambiguity in my thoughts that Jigsaw is a bad idea and can't move forward as is.
> How can Oracle get to this point in the process without more buy in from the community?
Not trying to be snarky, but you've never worked with Oracle, have you? Their modus operandi is to literally make whatever it is they want, then kick it out the door and tell everyone: look at what we did, deal with it. They have absolutely no idea how to collaborate. With partners or customers. They've had 20+ years of "our way or the highway". The house Larry built.
Stop talking nonsense. Oracle is a massive company.
There are different groups with different cultures especially since many of them arrived through acquisitions. Including the Java team which came from Sun.
The Java folks have no more control of corporate policy than the Solaris folks did. You're fooling yourself if you think they've got any control whatsoever.
Did those Java folks also decide to start extorting customers?
If the answer is yes - then they're no better than the Oracle folks they work for. If the answer is no, then they clearly have no say in what REALLY happens when it comes to Oracle's decision making.
Oracle is suing companies that explicitly enable commercial features of its commercial JVM. Next up: Microsoft broke my "free" copy of Windows XP, are they evil? /s
I don't have direct experience of this, but the general accusation I see is that companies hire Oracle to set up their systems, and Oracle's own people swear on a stack of bibles that the setup is in compliance, but behind the scenes they'll have enabled things that require more expensive licenses, and which Oracle knows are enabled and knows they can come back to shake you down for (sorry, "audit") later on.
They made their implementation of Java a commercial product and have been supporting OpenJDK for those that don't want to purchase it. They are are well within their right to sue companies who are illegally using a commercial product without a license. Just like Microsoft et al regularly sues companies who are pirating their software.
And no the developers who are responsible for Java are not lawyers in their spare time.
Yeah I'm really wondering how they got to this point, weeks away from release, and suddenly everyone realizes that Java modules have serious technical issues. Smells like 100% politics.
Not a lot of people have played with Jigsaw: it is hardly a thing you can play with in an afternoon. For those of us who have played with JDK9, it was pretty clear that this would be disastrous for a while. The continuous delay of Jigsaw is a good hint about how much impact it has.
If the fact they do it at this point is evidence of politics, can you explain why saying exactly the same thing much sooner would not have been? Jigsaw hasn't been in a state that most people can go try it for very long -- and most people are the folks who are impacted the most (for reasons the RH blog post explains).
Finally: it's not like Red Hat blocked this. A majority of stakeholders did, and most of them don't own module systems.
> Not a lot of people have played with Jigsaw: it is hardly a thing you can play with in an afternoon.
Presumably the people voting on it have.
> can you explain why saying exactly the same thing much sooner would not have been?
Because letting it get this far (weeks? from release) and then suddenly objecting loudly seems a little fishy versus bringing up technical objections years ago when there would be adequate time to address them?
This is not the first time those people have complained about Jigsaw by any stretch; it is the first time it has come to a vote and people felt it was worth to summarize the arguments. Oracle didn't even think Jigsaw was ready for a long time, which is why it didn't _even come to a vote previously_ and has delayed Java 9 by months. The release cycle was supposed to be 2 years, and Jigsaw is the only reason it isn't.
Jigsaw has been a project for... a decade? now. That isn't a consequence of easy consensus.
It is the first time people who aren't voting, Java programmers, could realistically try Jigsaw.
On 2017-05-03 Red Hat voted No with the following comment:
Red Hat is voting NO on this JSR. The Red Hat middleware team, other members of the EC and Java community members, have mentioned publicly and in more detail our concerns (here
https://developer.jboss.org/blogs/scott.stark/2017/04/14/cri... and here
https://developer.jboss.org/servlet/JiveServlet/download/38-...). We have also discussed with our own OpenJDK team, which made good counter arguments to several of the concerns, but in the end we believe a NO vote is the correct course of action. In previous votes and comments on the EG list we have articulated the view that from a middleware/SE developer perspective we believe that Jigsaw does not fulfil its original goals of being a module system which can be used by the likes of Java EE. We understand that after inception the original goals of the EG were initially changed to try to focus it on a module system to be used solely to modularise the JVM and that caused some architecture and implementation approaches which made it difficult for it to be a module system to be used by SE and EE developers. Unfortunately during the lifetime of the EG the goal appeared to switch back to trying to make it a module system for Java developers but previous implementation decisions appear not to have been revisited or could not be changed and as a result the expectations around Jigsaw have not been met by the implementation. Therefore, we are worried about the impact of the current implementation on the wider Java community, particularly existing projects and products including, but also beyond, Java EE. We have raised several issues within the EG list to try to rectify a few of these things in what we believe would have been a minimally invasive manner but they have been rejected. Furthermore, we believe that there has been insufficient consensus in the EG for a series of changes so dramatic to the JVM and which could have an equally dramatic impact on the Java communities, as well as a lack of openness on receiving and discussing community input. We believe that a more considered evaluation of all input and consensus gathering should not take too much time and would result in something which would be better received by the entire Java ecosystem.
Are IBM and RedHat just against Jigsaw because of commercial interests in JBoss Modules and OSGI?
It's been a while since I touched JBoss, but at one time they had gone wholesale for OSGI as their module system (replacing their old homegrown system built on JMX). Have they since replaced OSGI with something else?
They have since ripped out any kind of OSGi support. They wrote their own module system [1]. It's basically their very fancy way set up their own class loaders. As far as class loader frameworks go it's one of the best out there, IMHO the best of any Java server or container. It gives you non-hierarchical class loading and is fully parallel capable. Applications in general don't have to deal with it unless they want to tweak class loading. Only extensions to JBoss/WildFly itself have to deal with it, mostly it's just XML descriptors.
I have no idea how the JCP works, but I find it odd that Google doesn't have a vote in this process. They're clearly one of the biggest users and developers of Java in the world, even if you discount Android. Did they choose to abstain from this process, or were they kept out somehow?
I was involved in these discussions when I was at Sun.. ten years ago! The major players and their opinions haven't changed. There is no solution that will please everyone.
I feel like some of these complaints, such as (edit: some of) those by redhat, could have actually been mentioned even before any development on jigsaw began.
It's a bit odd to me that these really large complaints come out now, instead of much earlier in the stage of JDK9. Maybe even before any work would have been done on red hat.
That seems like a valid concern, which could have been made much earlier. Or maybe they have but people decide to push on with jigsaw anyway?
I did not really follow JDK9 development all that much, apart from the occasional blog. But it just feels to me like at least _some_ of these issues should have been raised much earlier.
I don't know the history of this, but it's entirely reasonable that this was a case of mismanaged expectations, a phenomenon that happens a lot in this industry.
In other words, maybe they thought Jigsaw will evolve into an OSGi replacement and it didn't, while introducing migration challenges. It's reasonable because the current implementation is an evolution of the original plan and maybe it evolved in a direction that Red Hat eventually disagreed with.
Of course, maybe this version was scaled back in order for it to be actually released, but note that the main complaint of the others voting No is that there's a lack of consensus on the open issues.
The "fragmentation of Java's community" will happen regardless, upgrades to Java 9 and Jigsaw will be slow, much slower than to Java 8. Consider that there are companies still on Java 6 and 7 and both have reached end of life. Along with an ecosystem of libraries that still maintain backwards compatibility.
If you're going to go through this migration pain, the benefit / cost ratio has to be worth it. Jigsaw has to solve big problems that Java developers face, to convince the community it's worth it, because projects and libraries have to be changed to support it, risking a very unhealthy fragmentation in that process.
Just because they've been written up and summarized for the vote doesn't mean they weren't aired before. Jigsaw has been delayed again and again and again, and that's not because it was an easy process.
How can one join the EC? Smaller and larger companies with very different focus, and even a community. Interesting.
Azul Systems, Inc. Yes
Credit Suisse No
Eclipse Foundation, Inc No
Fujitsu Limited Yes
Gemalto M2M GmbH Yes
Goldman Sachs & Co. Yes
Grimstad, Ivar No
Hazelcast No
Hewlett Packard Enterprise No
IBM No
Intel Corp. Yes
Keil, Werner No
London Java Community No
MicroDoc Yes
NXP Semiconductors Yes
Oracle Yes
Red Hat No
SAP SE No
Software AG No
SouJava Yes
Tomitribe No
Twitter, Inc. No
V2COM Yes
"Finally, we adjure all members and the spec lead to come back to the table and communicate directly to each other instead of blaming each other through blogs and open letters!"
Ouch, can anyone explain this drama and attitude to me? I've seen it ruin or stall the development of language or platforms multiple times now.
Jigsaw would have helped thousands of developers. Yes it does not solve all use cases, but no none of the use cases are solved.
Killed for political reasons because OSGi/IBM/Redhat and money. What the OSGi evangelists would not understand is how Jigsaw does not aim to solve the same problems as OSGi.
Bonus: If OSGi was a good thing, most developers would use it after decades of existence compared to practically noone. Which proves that OSGi does not solve the problems of the mainstream developer, which means making Jigsaw into OSGi-NG is not the way to go.
I am afraid this is the death knell for the Java community process. I simply don't see Oracle taking out Jigsaw from Java 9 after investing so much effort into it. Also, a lot of folks were looking forward towards Jigsaw as a lightweight module system compared to heavyweight OSGi.
My guess is that they will work closely on open issues with the community and after they are resolved (2-6 months) they will vote again and get enough votes to include it in JDK 9.
I prefer if oracle does not take it out. Most of the No votes are clearly politics, which is ridiculous considering sprit of JCP which wants to improve javas community . So i prefer oracle step in .
I like to think of the Java ecosystem as a giant elephant balancing on one leg, careening downhill on its squeaky little JVM roller skate.
I still remember that Java started as a toy language. And for all its security features and incremental improvements to JVM byte codes over the years, it still looks like a toy.
The classloader is the roller skate and the zillions of interoperating jars are the elephant. For the most part, the elephant stays up and continues blasting down that hill.
I used to think the scene was funny, but now I'm uncertain. Only through tools like Gradle and Maven have we papered over the inadequacies of the classloader system and gotten some control of it.
I had hopes that jigsaw would give the elephant an option of a little car to drive or at least a second skate to aid with balance. But safety trumps all, and such a huge breaking change should be avoided if we can.
I disagree. I'm very fond of the way Java classloaders work, and how they let me do non-trivial things with relative ease.
Tools like Maven don't solve anything related to classloading in my book. All they do is make it (a lot) easier to figure out dependencies. Judging by the "no"-votes, I doubt Jigsaw would have made that much easier.
As for the Java ecosystem, it seems to be doing better than ever. Can you elaborate on why you think the roller skate is squeaky and about to topple?
> Can you elaborate on why you think the roller skate is squeaky and about to topple?
Maybe 'topple' is taking things a bit too far since Java works far more often than it doesn't. How about 'teetering'?
But the roller skate is most definitely squeaky, and that's mainly because of the lack of help and organization that the built-in java systems give. I can reference two incompatible versions of libraries and the classloader will blithely load from both of them. You can claim "pilot error", but I reply that it's 2017 and we have huge memories and processors that we aren't using effectively to abstract the problem.
Why are we allowed to slam together these huge, sloppy code edifices atop a system that otherwise puts so much focus on security and safety?
Along with the standard "jar hell" arguments, I've got problems mixing cantankerous legacy spring and pre-spring era jars with post Java 8, CDI, JavaEE, etc jars. I need to containerize/componentize these assets and keep them separate from one another because they don't play nice nice with each other. Sure, I can roll my own JarClassLoaders and build a separation between groups of jars by-hand, but I never would because I want the computer to do that work for me - hence "modules".
In my opinion, if tools like Maven don't solve anything related to classloading in your book, then you are either:
1) off in your own corner rolling classpaths by hand and checking your .jar files into Git, or
2) you aren't working effectively at-scale on large software projects with groups of other people
In my case, Gradle was a revelation - it is a Groovy DSL veneer over Ant and Ivy, and it makes rolling custom classloaders extremely pleasant. Maven is very unpleasant because of its declarative XML language, but the Maven artifact coordinate scheme was a brillant stroke. I'm happy the Gradle folks were so successful in melding the platform compatibility tools of Ant, the artifacts of Maven, and the expressiveness of Groovy into a build system that even a dummy like me can grok and use effectively.
I rather like the declarative style of Maven. Maybe I'm just resisting change, but I don't like gradle. It requires too much "programming" for a build tool. But I agree with your statement about Maven/Gradle's dependency resolution magic.
The times where I've struggled with incompatible version conflicts and the like have not been numerous enough to count. A little bit of caution goes a long way, I think.
Incidentally, the only times I have been affected by this were while using IBM or Oracle components which rely entirely too much on global and environment settings.
> Maven is very unpleasant because of its declarative XML language
Maven was intended to be configured via a GUI. If you want to configure it directly, try Polyglot Maven at https://github.com/takari/polyglot-maven which is a very light wrapper around Maven enabling you to use many other languages instead, e.g. Scala, Clojure, and Ruby as well as Apache Groovy.
The Gradle people marketed their product by slagging the XML which was never intended to be directly manipulated by humans. If you really want to use Gradle (and get a coffee whenever it builds something), it also lets you use Kotlin for writing build files.
This is something I didn't know. Did the maven company, Sonatype, ever produce such a tool? It seemed to take years for Java IDE's to finally interoperate seamlessly with maven (was it 10 years for Eclipse?), and by then Gradle was popular and set to unseat it.
I use Gradle daemon when performance becomes an issue, and Gradle is fast enough with that. Maven is no performance superstar.
The maven plugin ecosystem also seemed impenetrable, whereas Gradle promoted plugin development and, lo and behold, they have a vibrant plugin ecosystem! The Maven XML language deserves to be slagged, it seemed designed to frustrate and hamstring the developer.
The classloader at runtime has to get its configuration from somewhere; that configuration is usually a static list of jars in a folder. That long list jars in the WEB-INF/lib folder doesn't magically appear.
Maven and Gradle have everything to do with runtime classloaders working properly and at-scale. Most developers don't know (or care) about all their transitive dependencies that get slurped into their projects.
What you've described is just one way a classloader can work, however, they can be implemented or hacked upon in a variety of ways.
Sure - maven does the work of resolving/flattening the dependency graph and downloading the libs - but it simply isn't a classloader.
That said, it might be possible to write a custom classloader which uses some bits of maven internally (provided there is a package to GAV index somewhere).
> Sure - maven does the work of resolving/flattening the dependency graph and downloading the libs - but it simply isn't a classloader.
Well, of course, but when was the last time you manually configured your classloader? How divorced are your classloaders from Maven, practically speaking? (That's what I was getting at - I wasn't trying for some pedantic sort of "maven constructs my java.lang.ClassLoader objects"-type thing.)
By manually, I mean supplying a list of .jar files and folders, or writing code that pumped classes into a custom classloader? Practically speaking, for any non-toy-sized project most people don't bother with that business anymore. They make deployment units, uber/shadow jars, or launch from a tool like Gradle that rolls their classloader for them from a Maven repository.
> That said, it might be possible to write a custom classloader which uses some bits of maven internally (provided there is a package to GAV index somewhere).
Ant, Gradle, and to a lesser extent, Maven serve as fine Java application launchers in that their dependency resolution engines can be targeted at the classpath-related arguments on the java and javac command lines.
Jigsaw would have provided (or will provide) a static compile time check of consistency. (And of course without jlink a start-up time check of consistency.)
That is helpful, but requires everyone to migrate to modules. So it's a kind of yes, but do we really need this? After all, we can just keep debugging shit when someone accidentally loads the wrong JARs.
All that automatic checking sounds really nice to me, but the devil is always in the details. It's a non-starter for me that Jigsaw was going to break so many existing programs.
Would it be possible to leave Java standard libraries alone but make Jigsaw-style modules available for new programs? That wouldn't make Java startup times any faster, which was one of the motivations for Jigsaw, but at least new apps could be architected for safety and consistency.
The problem is such an approach unfortunately does not work with changes to one of the largest programming languages on the planet, especially one that moves as slow as Java. Jigsaw cannot afford to be pushed out half-baked, Java has long prided itself on backwards compatibility and right now we're looking at a Python 2/3 split that will do serious harm to the ecosystem.
No love for Oracle here (except for all the money they spend having talented engineers work on the JVM. ie fuck their databases).
It's still laughable to call IBM and RedHat a community. They're consultants. Government consultants, mostly. This is an entrenched politics play and surprisingly, Oracle is playing the part of the little guy by virtue of not giving enough of a shit to micromanage the Java ecosystem.
Unfortunately Jigsaw is not a replacement for OSGi, this being a valid complaint, since it's a disruptive upgrade for the Java community, while not delivering much.
They were finally getting to have a fully built out environment - which could lead to better end user packaging, stripping down a library to its bare essentials.
For instance: what have jpackage achieved for a distribution like RedHat? Does anyone's Java App even pick up these RPM based dependencies for Classpath? Heck no.
Every known large scale Java application pretty much bundles a bunch of JARs. (Probably not logstash - but only one exception)
It is very clear that JDK9 will not be as awesome as it was originally supposed to be. Deeply disappointed.
can somebody provide a bit of background? I was looking forward to JDK 9 modules, but i didn't spent much time reading into it. I am quite surprised that it was voted down, since i think introducing modules is a step in the right direction. Also, judging from the comments, it seems that there will be a second vote?
The link also has the feedback given by the EC; check out the comments from Red Hat.
That covers a lot of it. To summarize:
Jigsaw started out as just a thing to modularize the JDK itself. It then tried to expand into being a general module system for java apps too. At which point, a whole bunch of concerns were raised about catering to needs that the JDK itself didn't have, but other things might.
At that point, the scope was reduced back down to just modularizing the JDK. And somewhere along the line the scope crept back _up_ to being a general module system, backed by a pretty big baseball bat: jigsaw breaks reflection and requires tons (as in, half a screen full if you're unlucky) of command line switches to make most libraries work.
So, there are now 2 concerns posited with the implementing team (with Mark Reinhold as the lead of that team): What can you do to fill needs that jigsaw does not fill and which we think the java community needs, even if _YOU_ (for the job of modularizing the JDK) do not, and, can you address the issues raised about how jigsaw makes it harder than it needs to be for existing java code to migrate, given that we've been here before (JDK4->JDK5 was a big update), and back then lots of projects effectively forced their users to stick to old versions of java for _years_, and those days weren't fun.
A few downvoters have voted this down because they think these are showstopping concerns and the EC hasn't given suitable answers.
However, most downvoters do not necessarily agree that these are showstoppers, but they have voted this JSR down because they feel the EC owes answers.
Given that Mark Reinhold has already shot down another attempt by Red Hat to suggest a way to address their concerns, right now it looks like this entire JSR is going to get killed in 30 days.
At that point, one of the following will happen:
* JDK9 will get delayed _A LOT_ because a new JSR will be started to continue work on jigsaw. Presumably the same issues will plague it so they'll have to be addressed after all.
* Oracle invokes the nuclear option and gets rid of the EC, or does something virtually as drastic by for example releasing 'oracle java 9' whilst not actually releasing a java 9 spec or the OpenJDK, or trying to eject Red Hat etc from the EC. Any attempt to do that will probably result in the EC voting down everything based on that alone, so, basically all these options lead to: No more EC.
* Jigsaw's scope is reduced to only being a way to modularize the JDK, probably still breaking lots of existing code (because of breaking reflection), but no EC vote is needed because oracle sells it as an 'implementation detail'.
* Jigsaw is removed entirely, and the efforts are refocussed for JDK10, under a new JSR number.
> right now it looks like this entire JSR is going to get killed in 30 days.
I don't think so.
I suspect Eclipse/IBM/RedHat will still vote against it, but the others will accept that voting "yes" is better than the alternatives (as you have described) and let it through.
There are a small number of members who think that Jigsaw if fundamentally bad. For them, it's solving the problem the wrong way, ignoring their beloved existing module systems, and is a waste of effort that ought to be killed. They will alway vote no, and will look for relevant technical reasons to justify that. And there's always something wrong with a spec if you want to find it. I don't specifically mean "this is political" so much as "they are predisposed to be against Jigsaw, and will always find flaws in it because they simply don't believe in it".
Most of the other members who voted no, seem to think that Jigsaw can be salvaged, but don't want to simply wave it through when there's still so much angst, and there's hope that, with time, some of that angst can be reduced and the spec will be improved along the way.
Once they get to the critical point where it's vote yes, or kill it entirely, that decision changes. At that point, voting no creates more angst and more problems, and won't improve the spec. I expect that they'll vote "yes" then, and accept that they got the best outcome that they could possibly achieve.
Perhaps there will be one or two who will still vote no because they don't think enough progress was made and they will take a principled position over a pragmatic one (which is not necessarily a virtue in a standard committee), but I think it will get through, simply because the alternative is so much worse.
ok, thanks. I've read the comments, but the perspective from somebody "neutral" is always enlightening. I don't know whether Jigsaw creates a lot of work for one of Red-hats core-products or whatever, thus i took Red-hats comments with a grain of salt.
Interesting to see NXP Semiconductors there. Being primarily a semiconductor manufacturer how do they use JVM based (Java etc) language ecosystem in their products? SDK to program their boards for development purposes?
NXP makes smart cards, which frequently run JCOS. This is an embedded OS for microcontrollers which runs on Java bytecode. However, they use Java bytecode version 1.2 and language level 1.3 with Stirings removed, so I don't know quite why they would be influincing later Java versions.
Excuse me. Could someone please explain why is goldman on the list? I do not think they are qualified as a reviewer based on their engineering standard.
Well I don't think even my nearest or dearest would call me adorable, but hey :-). The module system proposal did state that the user module system was a non goal, but the design of it means that it does impact existing user module systems (OSGi, JBoss) as well as the defacto build / package system (Maven) and so several EC members felt that more interop work is required.
I have little idea about cars (Java), but in carpet land (JS): we had the largest module ecosystem ever and it was pretty much ignored by TC39 in favor of a new solution, which has technical benefits (it's async), but there's no migration path from the current standard to the new anointed 'standard'. Sometimes technical committees just refuse to pave cowpaths. Look at the amount of lines it takes to do an XHR in the 'fetch' API vs superagent in, say, 2012.
I'm very interested in what "largest module ecosystem" you were referring to and what you mean by "the amount of lines it takes to do an XHR in the 'fetch' API vs superagent in, say, 2012."
AFAIK, there was a time when the "module ecosystems" were essentially split between requirejs (AMD) on the front and CJS in the back.
Fetch is also not XHR, and has different security defaults and trade-offs.
CommonJS (via npm) is used on more front-end code than TC39 modules are to this day.
I should say 'HTTP request' rather than XHR but the point still stands: having different objectives doesn't make it OK to ignore mime types, have people manually encode JSON, have people manually encode query strings, and all the other things we already have now in fetch. Which nobody will use (unless they want to cancel requests) because we already have better solutions with less needless boilerplate.
TC39 had been talking about JS modules for about decade, before CJS even existed. CJS is unsuitable on the frond end because it's synchronous and does not enable static analysis. CJS being more popular on the front end is a very recent phenomenon, it really started to take off when React took off. AngularJS had its own module system and everything jQuery were essentially AMD first.
I also don't know what you are talking what we already have in fetch. It you are arguing WHATWG should have just adopted superagent, I disagree. The major difference between fetch and XHR is the ability to stream content. Fetch only needs to be better than XHR. Superagent uses XHR internally, and it's extremely difficult to have XHR support streaming without turning its API to an even bigger mess. Encoding JSON yourself is a one-liner in JS. Encoding query string is also easy, there's a whole new URL object to help you now. If not, it's just a tiny function away. It's not hard to wrap fetch at all.
The Node module system was not "ignored". The folks I know on TC39 talked about it constantly. "export default" was added specifically for compatibility with Node.
The poster is emphasizing that their knowledge stems from a completely different industry but similar circumstances might provide useful insights into the issue.
Most no votes are only because they are concerned about their might with the JCP....
This is a sad day for software development.
... is concerned about the lack of a healthy consensus among the members of the Expert Group
From our point of view the lack of consensus inside the EG is a dangerous sign
I understand IBM's and others reason for their "No" vote and heard many similar concerns by e.g. the OSGi community or contributors behind major build systems like Maven, Gradle or Ant. Most of their concerns are still unanswered by the EG or Spec Leads
What we are especially concerned about however, is the lack of direct communication within the expert group
We echo ... comments in that we absolutely recognize the tremendous achievements and the great work that has been carried out until now by the EG members as well as (and especially) by the Spec Lead himself.
policits will either delay Java 9 or completly kill it. some people just want to show their teeth. sad.
How is this politics? They raise specific technical concerns by, amongst others, the de facto package manager! Who would have to raise concerns for you to not simply dismiss this as teeth-baring?
they don't raise specific technical concerns.
they want to have more time to address/disucss stuff about the specification. also maven is not the de facto package manager. the only thing which might be defacto is the publishing style, however there are many other package manager in the java world.
also a lot of this stuff could've been cleared up way way earlier.
p.s.: even if the one outlined is not a policitcal move, some votes definitly are.
None of those other package managers have had their issues (mostly the same) addressed either; it's a lowest common denominator: people are complaining that _not even_ Maven has been addressed.
Even if it were true that somehow Maven isn't the de facto package manager (I disagree), it is certainly more than big enough that the JCP doesn't get to casually ignore its existence.
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.