TLDR
We voted No because we want to see final consensus on the last few outstanding issues as well as some bedding in time of recent, far-reaching consensus decisions. No we don’t think this should or will delay Java 9 significantly, we expect a re-submission and eventual “Yes” vote to this specification within 30 days, please see the JCP Process Document for how this works. No, we don’t think JPMS/Jigsaw is fundamentally flawed. Yes we want extra time and thought going into JPMS by the wider ecosystem (and its authors) as this new module system will impact Java far more than the move to generics in Java 5.
The results of the vote on the Public Review for this JSR are here: https://jcp.org/en/jsr/results?id=5959
Our official comment
We echo SAP’s 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.
The LJC is voting “No” on the spec *as it was submitted* at the start of the voting period. During the 14 day voting period, great progress was made by the Spec Lead and the EG to reach consensus on some very difficult issues such as #AutomaticModuleNames. However, there are still on going conversations on some of those issues and there simply has not been enough time spent by the ecosystem to discuss some of the new designs in enough depth or enough time spent implementing and testing prototypes based on the latest spec, e.g. The Eclipse ejc compiler or the latest Automatic Module Naming design in Maven.
If required, we very much look forward to being able to vote ‘YES’ in <= 30 days on a version that has had that little bit of extra time for the EG (and the ecosystem) to discuss / implement / test some of these difficult spec items. Certainly the last 14 days have shown that consensus can be reached even when viewpoints have started in opposing corners, and we think another short time period to really bed in the last sticking points is needed.
Further Notes
We voted “No” based on careful technical analysis of JPMS, the RI (Jigsaw), comments on the mailing list as well as out in other public forums. We then put the existing specification to the test on a Java 9 hackday along with the Virtual JUG and ~15 JUGs worldwide. The conclusion was that JPMS still has some outstanding issues to be resolved or issues that (despite having recent resolutions), were still not bedded in the minds and/or prototypes of the larger ecosystem.
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. Although consensus is rapidly forming around those two items, our membership felt that they needed some extra time before they felt comfortable with voting “Yes”.
This is what the JCP is for (no, not just politics)
Casual observers and some parts of the tech media will likely come to the conclusion that this is all just about big company politics. Recent public blog posts and open letters will have fuelled that sentiment, but we urge people to read the comments accompanying “No” votes.
Although Oracle are the stewards of Java, the JCP Executive Committee (EC) is meant to act as guide for the Java ecosystem as a whole and we feel strongly that it is working as intended in this case.
What next?
4 comments
Comments feed for this article
May 16, 2017 at 10:28 pm
JCP ECはJavaプラットフォームモジュールシステムに反対票を投じた – InfoQ Japan – 経営学
[…] JPMSに反対する票はないと見る人もいるかもしれないが、現時点のJSRはまだ作業中であり、 最終投票に行く前に解決の必要がある粗い部分があるというのが現実である。パブリックレビューは30日間以内なら再実施できる。パブリックレビューはさらなる問題を特定すべきで、その後問題を明らかすることができる。しかし、一度JSRがパブリックレビューを通過すると、最終レビュー投票に入る。これは再実施できず、まさに最終である。OpenJDKの実装(コードはすでにある)に影響はしないが、他のJavaプロバイダがJavaに準拠するために実施する必要があることに影響するだろう。オラクルにとっての代替案は完了していない仕様を急ぎで終わらせるための手段としてJCPを変更するか解散することだ。Martijn Verburg氏はロンドンJavaコミュニティのブログに投稿し、LJCが反対票を投じた理由を説明した。 […]
May 31, 2017 at 8:29 am
Java Annotated Monthly – June 2017 | IntelliJ IDEA Blog
[…] Explanation of our “No” vote on JSR 376 (covers a number of the community concerns and makes predictions about what happens next) […]
January 30, 2018 at 2:47 pm
9 code and framework trends to watch in 2018 - Best Application Development Vendors, Resources, and Platforms
[…] Project Jigsaw, a proposed implementation of Java modules. Verburg and others worried that Jigsaw would harm the industry, so they asked for […]
July 9, 2018 at 11:30 am
5 Code And Framework Trends To Watch Out For In 2018
[…] Jigsaw, a proposed usage of Java modules. There was hype that passed around that Jigsaw would harm the business, therefore the demand for modification was made. Soon after that, Oracle suggested that the […]