36 ms·

JDK 9 modules voted down by EC

317 points by virtualwhys 9y ago

cakeface 9y ago
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.
- xienze 9y ago
  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.
  - lvh 9y ago
    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.
    - xienze 9y ago
      > 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?
      - lvh 9y ago
        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.
  - deleted 9y ago
    [deleted]
- PerryCox 9y ago
  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/critical-deficiencies-in-jigsawjsr-376-java-platform-module-system-ec-member-concerns https://developer.jboss.org/blogs/scott.stark/2017/04/14/cri... and here https://developer.jboss.org/servlet/JiveServlet/download/38-155022/JSR376.pdf 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.
- mindcrime 9y ago
  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?
  - needusername 9y ago
    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. [1] https://github.com/jboss-modules/jboss-modules https://github.com/jboss-modules/jboss-modules
- snuxoll 9y ago
  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.
- lvh 9y ago
  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.
  - specialist 9y ago
    "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 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.
    - lvh 9y ago
      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.
      - specialist 9y ago
        "anything Red Hat does is intrinsically bad" 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.
- tw04 9y ago
  > 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.
  - fs111 9y ago
    well, but the java folks at Oracle are all old Sun people and they are a lot different than Oracle-Oracle people.
    - grogenaut 9y ago
      Are they really still there?
      - haimez 9y ago
        Yes.
    - tw04 9y ago
      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? https://www.theregister.co.uk/2016/12/16/oracle_targets_java_users_non_compliance/ https://www.theregister.co.uk/2016/12/16/oracle_targets_java... 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.
      - threeseed 9y ago
        How are they extorting customers ? 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.
deleted 9y ago
[deleted]
nailer 9y ago
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.
- chickenfries 9y ago
  What do you mean by cars and carpet?
  - akoumis 9y ago
    The poster is emphasizing that their knowledge stems from a completely different industry but similar circumstances might provide useful insights into the issue.
  - bdcravens 9y ago
    Also drawing distinction between Java and JavaScript naming, as they really aren't related aside from those first few letters.
- wyuenho 9y ago
  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.
  - nailer 9y ago
    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.
cbr 9y ago
Why Red Hat voted no: https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical-deficiencies-in-jigsawjsr-376-java-platform-module-system-ec-member-concerns https://developer.jboss.org/blogs/scott.stark/2017/04/14/cri...
LeanderK 9y ago
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?
- rzwitserloot 9y ago
  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. * Even crazier things.
karlmarx14 9y ago
Very nice
readams 9y ago
It's really a shame as OSGi is a nightmare.
- bad_user 9y ago
  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.
- mindcrime 9y ago
  How so? OSGI works very well in my experience.
bad_user 9y ago
Red Hat has voiced their concerns in the following document, linked in their comment: https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical-deficiencies-in-jigsawjsr-376-java-platform-module-system-ec-member-concerns https://developer.jboss.org/blogs/scott.stark/2017/04/14/cri... Found a follow up in this blog post: https://blog.plan99.net/is-jigsaw-good-or-is-it-wack-ec634d36dd6f https://blog.plan99.net/is-jigsaw-good-or-is-it-wack-ec634d3... 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".
- ygaf 9y ago
  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.
thowaway60 9y ago
Voted down? What do you mean?
Yhippa 9y ago
Am I interpreting Reinhold's comments correctly: Jigsaw isn't perfect but we need to get something out there, see what breaks, fix it, and iterate?
- snuxoll 9y ago
  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.
  - pulse7 9y ago
    Agree! Java Module System needs another 6-9 months for polishing, especially in the backwards compatibility area.
- ratherbefuddled 9y ago
  How many years are we expected to wait for the fixes? The key to the "go fast, break things, fix them" approach is that you have to go fast.
Insanity 9y ago
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. Such as noted here https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical-deficiencies-in-jigsawjsr-376-java-platform-module-system-ec-member-concerns?_sscc=t https://developer.jboss.org/blogs/scott.stark/2017/04/14/cri...: > Fragmentation of the Java community 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.
- bad_user 9y ago
  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.
- lvh 9y ago
  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.
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.
frik 9y ago
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
- avar 9y ago
  How to become a member & associated rules are covered in their procedures documentation: https://jcp.org/en/procedures/jcp2#3.2.2 https://jcp.org/en/procedures/jcp2#3.2.2
- WaxProlix 9y ago
  And an individual - Ivar Grimstad. Most surprising one there for me.
- exabrial 9y ago
  Also of note: SouJava. They're an organization, not a company
yegortimoshenko 9y ago
The single most important feature of Java is reverse compatibility. It is a temporal prerequisite of "write once, run everywhere".
- treehau5 9y ago
  "write once, debug everywhere".
  - Tostino 9y ago
    I've had very little of that personally. Every project I've worked on has had no compatibility issues on different platforms.
- threeseed 9y ago
  Do you mean forwards compatibility ? I can't take Java 1.8 code and run it on a Java 1.7 JVM.
  - slrz 9y ago
    The 1.8 JVM implementation is compatible with the interface provided by earlier ones. That's what's meant by backwards-compatible.
apetresc 9y ago
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?
- mikeevans 9y ago
  I don't know for sure, (https://jcp.org/en/participation/committee https://jcp.org/en/participation/committee shows they were in 2013) but I suspect Oracle v Google might be the reason?
amyjess 9y ago
Bye bye JCP then. Oracle's just going to go it alone from now on.
- lvh 9y ago
  If the JCP isn't allowed to disagree, it was never much of a Community Process, and we were in Oracle-runs-the-show all along. I wonder what Oracle will do; burning the JCP is not something that will go unpunished.
  - haimez 9y ago
    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.
deleted 9y ago
[deleted]
popopobobobo 9y ago
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.
- detaro 9y ago
  They are there because they were elected by participants in the JCP program, as a representative of Java users.
- shiv86 9y ago
  What engineering standard are you referring to ?
  - popopobobobo 9y ago
    slang...
CodeSheikh 9y ago
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?
- artemist 9y ago
  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.
  - pjmlp 9y ago
    They also make IoT devices with Java on them. http://www.nxp.com/assets/documents/data/en/reports-or-presentations/DWF13_APF_ENT_T0887.pdf http://www.nxp.com/assets/documents/data/en/reports-or-prese...
- pjmlp 9y ago
  You can get some information here http://www.nxp.com/assets/documents/data/en/reports-or-presentations/DWF13_APF_ENT_T0887.pdf http://www.nxp.com/assets/documents/data/en/reports-or-prese...
crudbug 9y ago
Glad to see this, not a fan of "requires / exports" keywords. Java packages already use import. So, logically export should be associated with packages not modules. Module being meta-package, should follow these. "requires <package>" "declares <package>"
karianna 9y ago
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/explanation-of-our-no-vote-on-jsr-376-java-platform-module-system/ https://londonjavacommunity.wordpress.com/2017/05/09/explana... - Happy to answer further questions although I've probably found this thread too late :-)
- kodablah 9y ago
  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?
  - needusername 9y ago
    I am not part of LJC nor do I speak for the LJC but I found the following thread very revealing: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012524.html http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/0...
    - kodablah 9y ago
      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.
EdSharkey 9y ago
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.
- Tharkun 9y ago
  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?
  - EdSharkey 9y ago
    > 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.
_pmf_ 9y ago
> Many disagree with circular module dependencies (I am one) at least at this initial stage. Does disagreeing with gravity allow you to fly?
- clhodapp 9y ago
  There is a strong argument that if two modules have a circular dependency, they ought to be a single module.
  - erikpukinskis 9y ago
    Or three modules. Or two modules without a circular dependency. When the going gets weird, good programmers move boundaries.
    - clhodapp 9y ago
      Fair point!
- sctb 9y ago
  Would you please stop posting unsubstantively? We've asked you several times already and eventually we ban accounts that won't.
  - oceanswave 9y ago
    Please take this elsewhere, as to your point, replies such as this are even further removed from the subject
    - sctb 9y ago
      Fair enough, we've detached the OP from https://news.ycombinator.com/item?id=14302499 https://news.ycombinator.com/item?id=14302499 and marked it off-topic.
lenkite 9y ago
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.
- cfontes 9y ago
  It will be indeed really incredible if they take it out without destroying the JCP. Sad times I guess.
- 0xFFC 9y ago
  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 .
- pulse7 9y ago
  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.
  - pulse7 9y ago
    And if another voting fails, they can make modules internal to the JDK and ship now modularized JDK and then rework and expose modules in one of the later versions.
inglor 9y ago
"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.
joshmarinacci 9y ago
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.
rattray 9y ago
For others who aren't familiar with Java's governing structure, EC = Executive Committee https://www.jcp.org/en/home/index https://www.jcp.org/en/home/index
_Codemonkeyism 9y ago
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.
merb 9y ago
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.
- lvh 9y ago
  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?
  - merb 9y ago
    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.
    - lvh 9y ago
      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.
haimez 9y ago
You are fucking adorable. A new collections library is so far off the table that it doesn't bare mentioning, but this whole vote is about compatibility. Last I checked, the module system proposal lists a user module system as a non goal, so what this has shown is that the JVM needs its own community process to keep external interests from paralyzing forward motion on the standards front.
- gred 9y ago
  Tone it down. I suspect karianna has done more for the Java community than you or I ever will.
- karianna 9y ago
  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.
- dang 9y ago
  > You are fucking adorable. Personal incivility will get your account banned on HN, so please don't do this again. We detached this subthread from https://news.ycombinator.com/item?id=14303745 https://news.ycombinator.com/item?id=14303745 and marked it off-topic.
guilt 9y ago
This is not a good thing. 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.
mal34 9y ago
Oracle (the neXt Micro$oft) is killing ex-Sun's Java language and software.
- keypusher 9y ago
  Oracle voted yes on this proposal.
  - SliderUp 9y ago
    Yes, that's his point.

317 points by virtualwhys 9y ago

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.

xienze 9y ago
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.
- lvh 9y ago
  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.
  - xienze 9y ago
    > 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?
    - lvh 9y ago
      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.
- deleted 9y ago
  [deleted]
PerryCox 9y ago
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/critical-deficiencies-in-jigsawjsr-376-java-platform-module-system-ec-member-concerns https://developer.jboss.org/blogs/scott.stark/2017/04/14/cri... and here https://developer.jboss.org/servlet/JiveServlet/download/38-155022/JSR376.pdf 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.
mindcrime 9y ago
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?
- needusername 9y ago
  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. [1] https://github.com/jboss-modules/jboss-modules https://github.com/jboss-modules/jboss-modules
snuxoll 9y ago
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.
lvh 9y ago
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.
- specialist 9y ago
  "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 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.
  - lvh 9y ago
    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.
    - specialist 9y ago
      "anything Red Hat does is intrinsically bad" 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.
tw04 9y ago
> 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.
- fs111 9y ago
  well, but the java folks at Oracle are all old Sun people and they are a lot different than Oracle-Oracle people.
  - grogenaut 9y ago
    Are they really still there?
    - haimez 9y ago
      Yes.
  - tw04 9y ago
    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? https://www.theregister.co.uk/2016/12/16/oracle_targets_java_users_non_compliance/ https://www.theregister.co.uk/2016/12/16/oracle_targets_java... 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.
    - threeseed 9y ago
      How are they extorting customers ? 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.

deleted 9y ago

[deleted]

nailer 9y ago

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.

chickenfries 9y ago
What do you mean by cars and carpet?
- akoumis 9y ago
  The poster is emphasizing that their knowledge stems from a completely different industry but similar circumstances might provide useful insights into the issue.
- bdcravens 9y ago
  Also drawing distinction between Java and JavaScript naming, as they really aren't related aside from those first few letters.
wyuenho 9y ago
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.
- nailer 9y ago
  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.

cbr 9y ago

Why Red Hat voted no: https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical-deficiencies-in-jigsawjsr-376-java-platform-module-system-ec-member-concerns https://developer.jboss.org/blogs/scott.stark/2017/04/14/cri...

LeanderK 9y ago

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?

rzwitserloot 9y ago
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. * Even crazier things.

karlmarx14 9y ago

Very nice

readams 9y ago

It's really a shame as OSGi is a nightmare.

bad_user 9y ago
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.
mindcrime 9y ago
How so? OSGI works very well in my experience.

bad_user 9y ago

Red Hat has voiced their concerns in the following document, linked in their comment: https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical-deficiencies-in-jigsawjsr-376-java-platform-module-system-ec-member-concerns https://developer.jboss.org/blogs/scott.stark/2017/04/14/cri... Found a follow up in this blog post: https://blog.plan99.net/is-jigsaw-good-or-is-it-wack-ec634d36dd6f https://blog.plan99.net/is-jigsaw-good-or-is-it-wack-ec634d3... 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".

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

thowaway60 9y ago

Voted down? What do you mean?

Yhippa 9y ago

Am I interpreting Reinhold's comments correctly: Jigsaw isn't perfect but we need to get something out there, see what breaks, fix it, and iterate?

snuxoll 9y ago
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.
- pulse7 9y ago
  Agree! Java Module System needs another 6-9 months for polishing, especially in the backwards compatibility area.
ratherbefuddled 9y ago
How many years are we expected to wait for the fixes? The key to the "go fast, break things, fix them" approach is that you have to go fast.

Insanity 9y ago

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. Such as noted here https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical-deficiencies-in-jigsawjsr-376-java-platform-module-system-ec-member-concerns?_sscc=t https://developer.jboss.org/blogs/scott.stark/2017/04/14/cri...: > Fragmentation of the Java community 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.

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

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.

frik 9y ago

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

avar 9y ago
How to become a member & associated rules are covered in their procedures documentation: https://jcp.org/en/procedures/jcp2#3.2.2 https://jcp.org/en/procedures/jcp2#3.2.2
WaxProlix 9y ago
And an individual - Ivar Grimstad. Most surprising one there for me.
exabrial 9y ago
Also of note: SouJava. They're an organization, not a company

yegortimoshenko 9y ago

The single most important feature of Java is reverse compatibility. It is a temporal prerequisite of "write once, run everywhere".

treehau5 9y ago
"write once, debug everywhere".
- Tostino 9y ago
  I've had very little of that personally. Every project I've worked on has had no compatibility issues on different platforms.
threeseed 9y ago
Do you mean forwards compatibility ? I can't take Java 1.8 code and run it on a Java 1.7 JVM.
- slrz 9y ago
  The 1.8 JVM implementation is compatible with the interface provided by earlier ones. That's what's meant by backwards-compatible.

apetresc 9y ago

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?

mikeevans 9y ago
I don't know for sure, (https://jcp.org/en/participation/committee https://jcp.org/en/participation/committee shows they were in 2013) but I suspect Oracle v Google might be the reason?

amyjess 9y ago

Bye bye JCP then. Oracle's just going to go it alone from now on.

lvh 9y ago
If the JCP isn't allowed to disagree, it was never much of a Community Process, and we were in Oracle-runs-the-show all along. I wonder what Oracle will do; burning the JCP is not something that will go unpunished.
- haimez 9y ago
  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.

deleted 9y ago

[deleted]

popopobobobo 9y ago

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.

detaro 9y ago
They are there because they were elected by participants in the JCP program, as a representative of Java users.
shiv86 9y ago
What engineering standard are you referring to ?
- popopobobobo 9y ago
  slang...

CodeSheikh 9y ago

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?

artemist 9y ago
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.
- pjmlp 9y ago
  They also make IoT devices with Java on them. http://www.nxp.com/assets/documents/data/en/reports-or-presentations/DWF13_APF_ENT_T0887.pdf http://www.nxp.com/assets/documents/data/en/reports-or-prese...
pjmlp 9y ago
You can get some information here http://www.nxp.com/assets/documents/data/en/reports-or-presentations/DWF13_APF_ENT_T0887.pdf http://www.nxp.com/assets/documents/data/en/reports-or-prese...

crudbug 9y ago

Glad to see this, not a fan of "requires / exports" keywords. Java packages already use import. So, logically export should be associated with packages not modules. Module being meta-package, should follow these. "requires <package>" "declares <package>"

karianna 9y ago

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/explanation-of-our-no-vote-on-jsr-376-java-platform-module-system/ https://londonjavacommunity.wordpress.com/2017/05/09/explana... - Happy to answer further questions although I've probably found this thread too late :-)

kodablah 9y ago
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?
- needusername 9y ago
  I am not part of LJC nor do I speak for the LJC but I found the following thread very revealing: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012524.html http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/0...
  - kodablah 9y ago
    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.

EdSharkey 9y ago

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.

Tharkun 9y ago
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?
- EdSharkey 9y ago
  > 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.

_pmf_ 9y ago

> Many disagree with circular module dependencies (I am one) at least at this initial stage. Does disagreeing with gravity allow you to fly?

clhodapp 9y ago
There is a strong argument that if two modules have a circular dependency, they ought to be a single module.
- erikpukinskis 9y ago
  Or three modules. Or two modules without a circular dependency. When the going gets weird, good programmers move boundaries.
  - clhodapp 9y ago
    Fair point!
sctb 9y ago
Would you please stop posting unsubstantively? We've asked you several times already and eventually we ban accounts that won't.
- oceanswave 9y ago
  Please take this elsewhere, as to your point, replies such as this are even further removed from the subject
  - sctb 9y ago
    Fair enough, we've detached the OP from https://news.ycombinator.com/item?id=14302499 https://news.ycombinator.com/item?id=14302499 and marked it off-topic.

lenkite 9y ago

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.

cfontes 9y ago
It will be indeed really incredible if they take it out without destroying the JCP. Sad times I guess.
0xFFC 9y ago
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 .
pulse7 9y ago
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.
- pulse7 9y ago
  And if another voting fails, they can make modules internal to the JDK and ship now modularized JDK and then rework and expose modules in one of the later versions.

inglor 9y ago

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

joshmarinacci 9y ago

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.

rattray 9y ago

For others who aren't familiar with Java's governing structure, EC = Executive Committee https://www.jcp.org/en/home/index https://www.jcp.org/en/home/index

_Codemonkeyism 9y ago

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.

merb 9y ago

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.

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

haimez 9y ago

You are fucking adorable. A new collections library is so far off the table that it doesn't bare mentioning, but this whole vote is about compatibility. Last I checked, the module system proposal lists a user module system as a non goal, so what this has shown is that the JVM needs its own community process to keep external interests from paralyzing forward motion on the standards front.

gred 9y ago
Tone it down. I suspect karianna has done more for the Java community than you or I ever will.
karianna 9y ago
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.
dang 9y ago
> You are fucking adorable. Personal incivility will get your account banned on HN, so please don't do this again. We detached this subthread from https://news.ycombinator.com/item?id=14303745 https://news.ycombinator.com/item?id=14303745 and marked it off-topic.

guilt 9y ago

This is not a good thing. 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.

mal34 9y ago

Oracle (the neXt Micro$oft) is killing ex-Sun's Java language and software.

keypusher 9y ago
Oracle voted yes on this proposal.
- SliderUp 9y ago
  Yes, that's his point.