
JDK 9 modules voted down by EC - virtualwhys
https://jcp.org/en/jsr/results?id=5959
======
lvh
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.

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

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

~~~
pitay
What has J2EE/Java EE been replaced with?

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

~~~
pitay
Ah, thanks very much for your reply.

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

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

~~~
karianna
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...](http://mail.openjdk.java.net/pipermail/jigsaw-
dev/2017-May/012524.html)

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

~~~
mike_hearn
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...](http://mail.openjdk.java.net/pipermail/jigsaw-
dev/2017-May/012560.html*)

~~~
annnnd
Fixed link: [http://mail.openjdk.java.net/pipermail/jigsaw-
dev/2017-May/0...](http://mail.openjdk.java.net/pipermail/jigsaw-
dev/2017-May/012560.html)

------
bad_user
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...](https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical-
deficiencies-in-jigsawjsr-376-java-platform-module-system-ec-member-concerns)

Found a follow up in this blog post: [https://blog.plan99.net/is-jigsaw-good-
or-is-it-wack-ec634d3...](https://blog.plan99.net/is-jigsaw-good-or-is-it-
wack-ec634d36dd6f)

Interesting to see Twitter voting No as well, with the comment " _Our main
concern is that it is likely that this JSR will prove disruptive to Java
developers, while ultimately not providing the benefits that would be expected
of such a system_ ".

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

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

~~~
lvh
Given the detail of the post RH put up, and the fact that many companies that
aren't RH also voted against, I think the onus is on the claimant to
demonstrate that politics are in fact involved. I disagree with a lot of what
RH does, have no stake in any voting party, but unambiguously think Jigsaw can
not go forward in its current state.

Releasing the JDK9 without Jigsaw enabled is not a major problem.

~~~
specialist
_" I think the onus is on the claimant to demonstrate that politics are in
fact involved."_

When has there ever been a technical decision made on the technical merits?

It's always politics. Scratch that. It's _only_ politics.

Pieter Hintjens' telling of how RedHat spiked the process around AMQP shows
that RedHat is no different from any other player.
[http://hintjens.com/blog:125#toc15](http://hintjens.com/blog:125#toc15)

I had a brief flirtation with a standardization effort. Standards bodies are
just another battlefield for belligerents. And I have no problem with that.

~~~
lvh
By that logic, literally anything Red Hat does is intrinsically bad. I did
misspeak: I'll happily believe there is some politics, but that's not what I
meant to say; the claim elsewhere is that it's purely or primarily politics.

I've already argued that simply reducing it to "it's politics" is not a
reasonable argument unless you can also explain why the RH technical detail
post is really just a bunch of politics and not technical arguments, and if
you can explain why all of these organizations that don't own a module system
_also_ voted against.

~~~
specialist
_" 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.

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

------
apetresc
I have no idea how the JCP works, but I find it odd that Google doesn't have a
vote in this process. They're clearly one of the biggest users and developers
of Java in the world, even if you discount Android. Did they choose to abstain
from this process, or were they kept out somehow?

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

------
joshmarinacci
I was involved in these discussions when I was at Sun.. ten years ago! The
major players and their opinions haven't changed. There is no solution that
will please everyone.

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

EC = Executive Committee

[https://www.jcp.org/en/home/index](https://www.jcp.org/en/home/index)

------
Insanity
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...](https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical-
deficiencies-in-jigsawjsr-376-java-platform-module-system-ec-member-
concerns?_sscc=t):

> Fragmentation of the Java community

That seems like a valid concern, which could have been made much earlier. Or
maybe they have but people decide to push on with jigsaw anyway?

I did not really follow JDK9 development all that much, apart from the
occasional blog. But it just feels to me like at least _some_ of these issues
should have been raised much earlier.

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

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

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

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

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

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

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

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

------
EdSharkey
I like to think of the Java ecosystem as a giant elephant balancing on one
leg, careening downhill on its squeaky little JVM roller skate.

I still remember that Java started as a toy language. And for all its security
features and incremental improvements to JVM byte codes over the years, it
still looks like a toy.

The classloader is the roller skate and the zillions of interoperating jars
are the elephant. For the most part, the elephant stays up and continues
blasting down that hill.

I used to think the scene was funny, but now I'm uncertain. Only through tools
like Gradle and Maven have we papered over the inadequacies of the classloader
system and gotten some control of it.

I had hopes that jigsaw would give the elephant an option of a little car to
drive or at least a second skate to aid with balance. But safety trumps all,
and such a huge breaking change should be avoided if we can.

~~~
Tharkun
I disagree. I'm very fond of the way Java classloaders work, and how they let
me do non-trivial things with relative ease.

Tools like Maven don't solve anything related to classloading in my book. All
they do is make it (a lot) easier to figure out dependencies. Judging by the
"no"-votes, I doubt Jigsaw would have made that much easier.

As for the Java ecosystem, it seems to be doing better than ever. Can you
elaborate on why you think the roller skate is squeaky and about to topple?

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

~~~
vorg
> 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](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.

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

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

~~~
snuxoll
The problem is such an approach unfortunately does not work with changes to
one of the largest programming languages on the planet, especially one that
moves as slow as Java. Jigsaw cannot afford to be pushed out half-baked, Java
has long prided itself on backwards compatibility and right now we're looking
at a Python 2/3 split that will do serious harm to the ecosystem.

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

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

~~~
lvh
If the JCP isn't allowed to disagree, it was never much of a Community
Process, and we were in Oracle-runs-the-show all along.

I wonder what Oracle will do; burning the JCP is not something that will go
unpunished.

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

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

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

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

------
LeanderK
can somebody provide a bit of background? I was looking forward to JDK 9
modules, but i didn't spent much time reading into it. I am quite surprised
that it was voted down, since i think introducing modules is a step in the
right direction. Also, judging from the comments, it seems that there will be
a second vote?

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

~~~
timv
> _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.

------
CodeSheikh
Interesting to see NXP Semiconductors there. Being primarily a semiconductor
manufacturer how do they use JVM based (Java etc) language ecosystem in their
products? SDK to program their boards for development purposes?

~~~
artemist
NXP makes smart cards, which frequently run JCOS. This is an embedded OS for
microcontrollers which runs on Java bytecode. However, they use Java bytecode
version 1.2 and language level 1.3 with Stirings removed, so I don't know
quite why they would be influincing later Java versions.

~~~
pjmlp
They also make IoT devices with Java on them.

[http://www.nxp.com/assets/documents/data/en/reports-or-
prese...](http://www.nxp.com/assets/documents/data/en/reports-or-
presentations/DWF13_APF_ENT_T0887.pdf)

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

~~~
threeseed
Do you mean forwards compatibility ?

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

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

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

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

~~~
shiv86
What engineering standard are you referring to ?

~~~
popopobobobo
slang...

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

~~~
keypusher
Oracle voted yes on this proposal.

~~~
SliderUp
Yes, that's his point.

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

Does disagreeing with gravity allow you to fly?

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

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

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

------
nailer
I have little idea about cars (Java), but in carpet land (JS): we had the
largest module ecosystem ever and it was pretty much ignored by TC39 in favor
of a new solution, which has technical benefits (it's async), but there's no
migration path from the current standard to the new anointed 'standard'.
Sometimes technical committees just refuse to pave cowpaths. Look at the
amount of lines it takes to do an XHR in the 'fetch' API vs superagent in,
say, 2012.

~~~
chickenfries
What do you mean by cars and carpet?

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

------
merb
Most no votes are only because they are concerned about their might with the
JCP.... This is a sad day for software development.

    
    
        ... is concerned about the lack of a healthy consensus among the members of the Expert Group
        From our point of view the lack of consensus inside the EG is a dangerous sign
        I understand IBM's and others reason for their "No" vote and heard many similar concerns by e.g. the OSGi community or contributors behind major build systems like Maven, Gradle or Ant. Most of their concerns are still unanswered by the EG or Spec Leads
        What we are especially concerned about however, is the lack of direct communication within the expert group
        We echo ... comments in that we absolutely recognize the tremendous achievements and the great work that has been carried out until now by the EG members as well as (and especially) by the Spec Lead himself.
    

policits will either delay Java 9 or completly kill it. some people just want
to show their teeth. sad.

~~~
lvh
How is this politics? They raise specific technical concerns by, amongst
others, the de facto package manager! Who would have to raise concerns for you
to not simply dismiss this as teeth-baring?

~~~
merb
they don't raise specific technical concerns. they want to have more time to
address/disucss stuff about the specification. also maven is not the de facto
package manager. the only thing which might be defacto is the publishing
style, however there are many other package manager in the java world. also a
lot of this stuff could've been cleared up way way earlier.

p.s.: even if the one outlined is not a policitcal move, some votes definitly
are.

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

