Hacker News new | past | comments | ask | show | jobs | submit login
JDK 9 modules voted down by EC (jcp.org)
317 points by virtualwhys on May 9, 2017 | hide | past | favorite | 184 comments

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)

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

What has J2EE/Java EE been replaced with?

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

Ah, thanks very much for your reply.

Worse that CORBA?

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

JVM size restrictability, higher-than-class-level modularity, module-level access restrictions, etc. Your question could be rephrased: "what are the common use cases that componentizing a runtime/stdlib solve?" Not everything is about the module ecosystem, package management, etc. Sometimes componentization has benefits itself without concern for additional features.

So, the final calculus is if the cost of having Jigsaw warrants the benefits that Jigsaw does provide. For me, the answer is clearly no.

"Modularity" is a word with a lot of meanings, and we're going to need to pin one down to discuss it meaningfully -- especially since competing module systems solve a different set of problems. To me, modularity is about isolation, and being able to run a lot of stuff together on a JVM that you previously couldn't; say because of incompatible versions of Guava or whatever. To you, it might mean "increased visibility restrictions". (I'm not arguing for one definition or another; just that we should probably agree on one.)

Can we agree that making JVMs smaller does not necessarily require Jigsaw, its JSP, or in fact anything that can meaningfully be described as a module system? Do we agree that splitting up the stdlib can have size and performance benefits without having to break the stuff Jigsaw breaks?

I don't think it breaks hardly anything except for those using many deprecated or internal items anyways. And if there are BC incompat concerns, they should be addressed specifically but they don't seem to be the primary reasons for "no". Sure we can agree that Jigsaw is not necessarily required for JVM modularization. But surely we could also agree that dogfooding a feature available to all is much better than an internal-only set of jmod files with their own internal-only way of being used. We all want the benefits of modularity especially wrt access restrictions across modules.

Reflection to sidestep visibility wasn't deprecated, and the bootclassloader's properties weren't internal AFAICT; both of those broke Clojure pretty heavily.

I'm not sure we can agree that the dogfooding is preferable. The penalty paid in the stdlib would have to be paid time and time again by users -- as it stands, Jigsaw is not something I can conveniently opt-in (or opt-out) -- it's very clear that the opt-out switches are temporary hacks, and even those don't make porting trivial. As someone who used to be very active in the Python community, I think the 2/3 comparison is very apt.

The problem with that is that nobody is backporting fancy compiler improvements to JDK8; I can't get my faster JDK without also buying into a module system I didn't want and also broke my code.

It is certainly not clear to me that stronger visibility restrictions are a priori desirable when they break dynamic hosted languages. Reflection as a side-stepping mechanism is already easy to detect and clearly opt-in by the reflector, and you've had the option of opting out for ages with Security Managers. All Jigsaw buys you is another level of granularity in that visibility (not just class, subclass, package) and breaking the workarounds for when you actually really mean it.

> Can we agree that making JVMs smaller does not necessarily require Jigsaw, its JSP, or in fact anything that can meaningfully be described as a module system? Do we agree that splitting up the stdlib can have size and performance benefits without having to break the stuff Jigsaw breaks?

I don't think we can unless there's an implementation proposal that takes that approach?

Certainly I think it would be impractical to make the JVM smaller without having visibility restrictions that apply even to reflective access. To be able to develop applications/library intended to run against a smaller JVM I need a way to restrict myself from using certain features even when developing on a full-sized JVM.

> This is unambiguously a good thing.

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

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.

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



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

> I don't think suggesting their vote against Jigsaw is somehow a political plot to benefit OSGi

RedHat and others clearly do want Jigsaw to be a meta-module system though, which to any sane person who has no financial interest in existing module technologies is ridiculous, and would be exactly the kind of mind-numbing complexity that people hate on Java for. Eclipse's No vote even came with this comment:

“The Eclipse Foundations looks forward to a revised specification which will enable independent implementations”

IBM Global Services always seemed to me to hire exclusively people with an exceptionally high tolerance for complexity (aka 'bullshit'). Every encounter I've had with them has been to build the most complex thing that they could keep running. Which is to say, you couldn't pay your people enough money to deal with it so you have to keep IGS around to maintain what they built. People get exasperated with their convolutions and basically say something like, "Look, whatever. Just do what you want and stop updating me on your latest travesty. I don't want to know." And then they win.

Every time I see their stuff it reminds me of those all-in-one woodworking machines (It's a drill press AND a lathe!) you used to see on infomercials when infomercials were still a new thing. Too goddamned many moving parts, things that can break, and ways you can lose a finger.

Any time I see IBM involved in a JSR, the IGS modus operandi is written all over it.

> Every time I see their stuff it reminds me of those all-in-one woodworking machines (It's a drill press AND a lathe!) you used to see on infomercials when infomercials were still a new thing. Too goddamned many moving parts, things that can break, and ways you can lose a finger.

You mean a Shopsmith? Those have been around since before infomercials, and they are still producing new versions. They're actually a decent combination wood lathe/horizontal boring drill press (which both already need the fancy variable speed drive), and there's nothing complicated about the disc sander that needs a separate machine. But yeah, the table saw option doesn't feel right...

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

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

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

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

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

Reading some of the "no" comments. Red Hat and IBM both have a list of reasons why they think Jigsaw is not ready.

As for the rest of the companies voting "no" it looks like it's mostly because "there is not a consensus amongst the EC". Which might be a fancy way of saying "If Red Hat and IBM don't approve then nor shall I".

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

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

I don't know. I can kinda understand real-world usage, but this reminds me of the objections when sun.misc.Unsafe was about to be removed.

A lot of the "missing features" seem like things that indicate design smells when used and that I would have looked forward to get rid of.

Maybe there are projects that have compelling use-cases for circular dependencies, heavy use of reflection or classpath introspection but those features impose a substantial cost on the language with relatively little returns. Why can't they be opt-in?

Both sun.misc.Unsafe and the introspection features you cite implement significant functionality that can't really be reproduced any other way. That's fine if all you care about is Java-the-language, but that decision just blew up JRuby, Clojure...

Sun.misc.Unsafe is still available and equivalent _safe_ functionality is being introduced before it is removed.and, most reflection stuff can be done public ancestors with a little care.

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

You mention Java again; so I'll mention JRuby and Clojure again. "It will cause some issues" is a serious understatement, and this is a clear violation of the (social) contract the JVM had. Enterprises use Java in no small part because they don't randomly break the billions of lines of Java code out there. s.m.U is a perfect example: they've wanted to break it for a while but aren't doing it until they can actually replace it.

A lot more software is broken by Jigsaw than would've been broken if s.m.U went away. Plus: there's an escape hatch: for better or worse, if s.m.U went away, you'd start seeing a whole ton more JNI.

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

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

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

> Meanwhile, significant incremental engineering benefits in JDK9 were being held back by this sweeping change; so now maybe we can just get a better JVM without breaking the world.

I think that was Jigsaw's biggest mistake: trying to build a strict module system that will allow modularizing the JVM and expecting that module system to be useful to Java developers, who are already using powerful userland module systems.

I frankly hope that the next iteration of Jigsaw just modularizes the JVM without exposing anything to userland.

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

> it's pretty awful for most things that aren't Java that target the JVM, like Clojure.

Curious, how does jigsaw make things awful for clojure?

Incomplete list:

- As a dynamic language, Clojure uses reflection extensively. Reflection becomes effectively opt-in in Jigsaw-land, breaking tons of Clojure software.

- JDK9 breaks dynamic classpath introspection and modification breaking java.classpath, dynapath (and hence CIDER &c).

- Clojure itself is no longer loadable from the new bootstrap classloader (clojure.inst requires java.sql.Timestamp). This matters, because being in the bootstrap classloader is a significant performance improvement.

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.

>clojure.inst requires java.sql.Timestamp

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

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?

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

> Jigsaw didn't solve the toughest problems it had hoped to solve

What was it?

As far as I know the JSR had a goal and the proposed JSMP spec is pretty much reaching that and nothing more.

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

It does matter.

Userland modules systems like OSGi can do whatever the fuck they can come up with during an enterprise occult architect-cult seance, but that is not mandatory for everyone else.

If the Java Platform does something stupid, you can't just sidestep the garbage and start from scratch.

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

There were concerns raised by the Eclipse JDT team (ecj authors) - starting here: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/0...

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

edit: seems there's something about it here:http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/0...

Hi Mike, yep - you've found one of the relevant threads.

I do not speak for the GP comment.

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.

I am not part of LJC nor do I speak for the LJC but I found the following thread very revealing:


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?

See http://mail.openjdk.java.net/pipermail/jpms-spec-experts/201... - I think this is a decent compromise and a majority of the Maven folsk seem to agree. We're hoping to take it for a test drive this Saturday at another Hackday.

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.


Yes, probably doing this incrementally (or at least as separately from "user land" as possible) would have been much better.

Though, this gives full program optimization via jlink, and probably modularizing rt.jar would have needed serious platform/syntax changes anyway.

What would you prefer instead?

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.

They go into quite a bit of detail in the blog post, including stuff like "no, you have to care about Maven".

Red Hat has voiced their concerns in the following document, linked in their comment: 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-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".

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.

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

re: feels like generics. Quite right. From Spec Lead, Mark Reinhold: https://youtu.be/fxB9cVNcyZo?t=41m50s

> unambiguously

You keep using that word. I do not think it means what you think it means.

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.

> I'm an ESL

In that case, you're doing very well indeed. I wouldn't have quoted The Princess Bride (watch it!) if I'd known.

Us foreign English-speakers, on occasion, do watch good movies. It's okay.


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

This. I used to work at IBM, and I can't tell you how many different (mutually inconsistent) narratives about "how IBM is".

well, but the java folks at Oracle are all old Sun people and they are a lot different than Oracle-Oracle people.

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.

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.

Are they really still there?


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.

[1] https://github.com/jboss-modules/jboss-modules

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 don't know for sure, (https://jcp.org/en/participation/committee shows they were in 2013) but I suspect Oracle v Google might be the reason?

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.

For others who aren't familiar with Java's governing structure,

EC = Executive Committee


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

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

And an individual - Ivar Grimstad. Most surprising one there for me.

How to become a member & associated rules are covered in their procedures documentation: https://jcp.org/en/procedures/jcp2#3.2.2

Also of note: SouJava. They're an organization, not a company

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

It will be indeed really incredible if they take it out without destroying the JCP.

Sad times I guess.

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.

> Maven was intended to be configured via a GUI.

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.

No... maven has little to do with classloaders which are primarily a runtime concern.

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.

Jigsaw is opt-in. It does exactly that.

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?

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.

Agree! Java Module System needs another 6-9 months for polishing, especially in the backwards compatibility area.

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.

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

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.

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.

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

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.

How so? OSGI works very well in my experience.

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.

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.

* Even crazier things.

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

They also make IoT devices with Java on them.


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

Do you mean forwards compatibility ?

I can't take Java 1.8 code and run it on a Java 1.7 JVM.

The 1.8 JVM implementation is compatible with the interface provided by earlier ones. That's what's meant by backwards-compatible.

"write once, debug everywhere".

I've had very little of that personally. Every project I've worked on has had no compatibility issues on different platforms.

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

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.

They are there because they were elected by participants in the JCP program, as a representative of Java users.

What engineering standard are you referring to ?


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

Oracle voted yes on this proposal.

Yes, that's his point.


> 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 and marked it off-topic.

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.

Tone it down. I suspect karianna has done more for the Java community than you or I ever will.

> Many disagree with circular module dependencies (I am one) at least at this initial stage.

Does disagreeing with gravity allow you to fly?

Would you please stop posting unsubstantively? We've asked you several times already and eventually we ban accounts that won't.

Please take this elsewhere, as to your point, replies such as this are even further removed from the subject

Fair enough, we've detached the OP from https://news.ycombinator.com/item?id=14302499 and marked it off-topic.

There is a strong argument that if two modules have a circular dependency, they ought to be a single module.

Or three modules.

Or two modules without a circular dependency.

When the going gets weird, good programmers move boundaries.

Fair point!

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.

> TC39 had been talking about JS modules for about decade, before CJS even existed.

Yep, which explains the ignorance. None of the other modules systems are a hundred thousandth the size of npm, so don't matter.

> I also don't know what you are talking what we already have in fetch.

Literally POST some JSON to a resource with a query and compare the code using superagent to the fetch API.

> Encoding JSON yourself is a one-liner in JS. Encoding query string is also easy.

That is irrelevant. Defaults should be sane.

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.

They just didn't adopt it wholesale.

What do you mean by cars and carpet?

Also drawing distinction between Java and JavaScript naming, as they really aren't related aside from those first few letters.

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.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact