JDK 9 modules voted down by EC
jcp.org
jcp.org
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.
As for the rest of the companies voting "no" it looks like it's mostly because "there is not a consensus amongst the EC". Which might be a fancy way of saying "If Red Hat and IBM don't approve then nor shall I".
Disclaimer: These are my views, not my employers, I'm not involved in the JPMS work.
RedHat and others clearly do want Jigsaw to be a meta-module system though, which to any sane person who has no financial interest in existing module technologies is ridiculous, and would be exactly the kind of mind-numbing complexity that people hate on Java for. Eclipse's No vote even came with this comment:
“The Eclipse Foundations looks forward to a revised specification which will enable independent implementations”
Every time I see their stuff it reminds me of those all-in-one woodworking machines (It's a drill press AND a lathe!) you used to see on infomercials when infomercials were still a new thing. Too goddamned many moving parts, things that can break, and ways you can lose a finger.
Any time I see IBM involved in a JSR, the IGS modus operandi is written all over it.
You mean a Shopsmith? Those have been around since before infomercials, and they are still producing new versions. They're actually a decent combination wood lathe/horizontal boring drill press (which both already need the fancy variable speed drive), and there's nothing complicated about the disc sander that needs a separate machine. But yeah, the table saw option doesn't feel right...
But I believe you could order a VHS casette (possibly for free) with the informational video long before infomercials became a thing. They just had one ready to go before anybody else.
I don't believe it's "unambiguously" a good thing. Many disagree with circular module dependencies (I am one) at least at this initial stage. Statements like "breaking the world" are a loaded way of saying "doesn't fit existing module use cases of all members". I think the current implementation was ripe for release and vendors would have worked with it well. I am also dismayed that a compete implementation can be completed before nixed (regardless of the internal reasons we got this far before turning back).
https://jcp.org/en/jsr/detail?id=294
http://javaposse.com/java_posse_259_jigsaw_and_jsr_294_inter...
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.
"Modularity" is a word with a lot of meanings, and we're going to need to pin one down to discuss it meaningfully -- especially since competing module systems solve a different set of problems. To me, modularity is about isolation, and being able to run a lot of stuff together on a JVM that you previously couldn't; say because of incompatible versions of Guava or whatever. To you, it might mean "increased visibility restrictions". (I'm not arguing for one definition or another; just that we should probably agree on one.)
Can we agree that making JVMs smaller does not necessarily require Jigsaw, its JSP, or in fact anything that can meaningfully be described as a module system? Do we agree that splitting up the stdlib can have size and performance benefits without having to break the stuff Jigsaw breaks?
I'm not sure we can agree that the dogfooding is preferable. The penalty paid in the stdlib would have to be paid time and time again by users -- as it stands, Jigsaw is not something I can conveniently opt-in (or opt-out) -- it's very clear that the opt-out switches are temporary hacks, and even those don't make porting trivial. As someone who used to be very active in the Python community, I think the 2/3 comparison is very apt.
The problem with that is that nobody is backporting fancy compiler improvements to JDK8; I can't get my faster JDK without also buying into a module system I didn't want and also broke my code.
It is certainly not clear to me that stronger visibility restrictions are a priori desirable when they break dynamic hosted languages. Reflection as a side-stepping mechanism is already easy to detect and clearly opt-in by the reflector, and you've had the option of opting out for ages with Security Managers. All Jigsaw buys you is another level of granularity in that visibility (not just class, subclass, package) and breaking the workarounds for when you actually really mean it.
I don't think we can unless there's an implementation proposal that takes that approach?
Certainly I think it would be impractical to make the JVM smaller without having visibility restrictions that apply even to reflective access. To be able to develop applications/library intended to run against a smaller JVM I need a way to restrict myself from using certain features even when developing on a full-sized JVM.
Having just implemented a plugin solution using it I can safely say that in the past 20+ years of software development it is the most awful technology I've ever seen. The complexity and over engineering is simply breath taking. It is worse than EJB 1.0, worse than the crazy abuses I have seen with Spring and DI, worse than than dark days of J2EE.
I have lost a lot of respect for Red Hat and IBM after this.
Let's hope the JDK doesn't adopt such wrongheaded approaches, and figures out a sensible way to implement modules. If they can't, then I'd be happy with the current state of third party opt-in approaches instead.
Simplicity -> usability && maintainability && security && popularity
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.
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.
Curious, how does jigsaw make things awful for clojure?
- As a dynamic language, Clojure uses reflection extensively. Reflection becomes effectively opt-in in Jigsaw-land, breaking tons of Clojure software.
- JDK9 breaks dynamic classpath introspection and modification breaking java.classpath, dynapath (and hence CIDER &c).
- Clojure itself is no longer loadable from the new bootstrap classloader (clojure.inst requires java.sql.Timestamp). This matters, because being in the bootstrap classloader is a significant performance improvement.
Just curious, why haven't they switched to java.time.LocalDateTime? Java 8 has been out for 3 years now.
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.
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.
It's pretty strange that just because Clojure uses SQL's Timestamp (why ?) that it should be a default.
Clojure uses it because it's the only sane time instance in the stdlib. It is not an uncommon class to use for that reason; the underlying reason is that j.u.Date sucks.
A lot of the "missing features" seem like things that indicate design smells when used and that I would have looked forward to get rid of.
Maybe there are projects that have compelling use-cases for circular dependencies, heavy use of reflection or classpath introspection but those features impose a substantial cost on the language with relatively little returns. Why can't they be opt-in?
Yes, this will cause some issues initially but I have hunk it's a good move for Java in the long term.
A lot more software is broken by Jigsaw than would've been broken if s.m.U went away. Plus: there's an escape hatch: for better or worse, if s.m.U went away, you'd start seeing a whole ton more JNI.
For instance, Leinigen putting itself on the boot classpath to get faster startup time is really a hack to work around the problem that Clojure apps do way too much stuff at startup and generates very old bytecode forms that takes a lot of work to verify. If you want to disable bytecode verification for Clojure apps you could just use -verify:none instead of blaming Java 9 for changing the way things are loaded at startup, which has never been a guaranteed property of the platform.
Lots of complex apps and language runtimes have been making assumptions about things that were never guaranteed or even documented and will need adjustment in Java 9, but that's OK - the prior situation was never sustainable and a big part of why Java 9 is taking so long and is such a big effort is to get the ecosystem onto a more sustainable, supported footing. Creating supported replacements for Unsafe stuff is one such example but there are plenty of others.
I really don't know much about Jigsaw, but I would have assumed it was also opt-in. That is, you can run Java 9 with circular dependencies and Clojure and anything that run on Java 8 - you just have to accept a large, monolithic JRE. Is that true?
What was it?
As far as I know the JSR had a goal and the proposed JSMP spec is pretty much reaching that and nothing more.
"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?
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/0...
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.
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).
edit: seems there's something about it here:http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/0...
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?
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.
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".
>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.
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.
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.
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?
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.
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?
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.
Releasing the JDK9 without Jigsaw enabled is not a major problem.
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.
I've already argued that simply reducing it to "it's politics" is not a reasonable argument unless you can also explain why the RH technical detail post is really just a bunch of politics and not technical arguments, and if you can explain why all of these organizations that don't own a module system _also_ voted against.
Not at all. I'm saying that politics is normal and good. I want RedHat, IBM, Oracle, etc to fight it out. Legally.
--
Before replying, I took a step back, wondering what my position is. Here it is:
This modules effort feels like generics. JDK 1.5 adopted the least objectionable, and therefore least useful, design for generics. The rationalization was "backward compatibility", then and now. The correct answer was to retool the JVM and JDK as needed to do generics properly.
IMHO, Java has leaned too far towards backward compatibility. But what do I know? Java continues to do quite well, despite my objections.
You keep using that word. I do not think it means what you think it means.
In that case, you're doing very well indeed. I wouldn't have quoted The Princess Bride (watch it!) if I'd known.
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.
Did those Java folks also decide to start extorting customers?
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.
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.
There are different groups with different cultures especially since many of them arrived through acquisitions. Including the Java team which came from Sun.
EC = Executive Committee
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.
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.
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 YesOuch, 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.
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.
Sad times I guess.
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.
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?
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.
Maven was intended to be configured via a GUI. If you want to configure it directly, try Polyglot Maven at https://github.com/takari/polyglot-maven which is a very light wrapper around Maven enabling you to use many other languages instead, e.g. Scala, Clojure, and Ruby as well as Apache Groovy.
The Gradle people marketed their product by slagging the XML which was never intended to be directly manipulated by humans. If you really want to use Gradle (and get a coffee whenever it builds something), it also lets you use Kotlin for writing build files.
This is something I didn't know. Did the maven company, Sonatype, ever produce such a tool? It seemed to take years for Java IDE's to finally interoperate seamlessly with maven (was it 10 years for Eclipse?), and by then Gradle was popular and set to unseat it.
I use Gradle daemon when performance becomes an issue, and Gradle is fast enough with that. Maven is no performance superstar.
The maven plugin ecosystem also seemed impenetrable, whereas Gradle promoted plugin development and, lo and behold, they have a vibrant plugin ecosystem! The Maven XML language deserves to be slagged, it seemed designed to frustrate and hamstring the developer.
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.
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).
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.
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.
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.
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.
I wonder what Oracle will do; burning the JCP is not something that will go unpunished.
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.
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.
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.
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.
http://www.nxp.com/assets/documents/data/en/reports-or-prese...
http://www.nxp.com/assets/documents/data/en/reports-or-prese...
I can't take Java 1.8 code and run it on a Java 1.7 JVM.
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>"
Does disagreeing with gravity allow you to fly?
Or two modules without a circular dependency.
When the going gets weird, good programmers move boundaries.
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.
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.
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.
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.
They just didn't adopt it wholesale.
... 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.
p.s.: even if the one outlined is not a policitcal move, some votes definitly are.
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.