Jigsawとして知られるJSR #376 JavaTM Platform Module Systemの、Public Preview Ballotでの各Executive Comitteeメンバーによる投票時のコメントをさらっと日本語化してみました（no commentのものは自明なので、日本語にしていません）。
原文はこちら。
https://jcp.org/en/jsr/results?id=5959
[Oracle]
On 2017-04-25 Oracle voted Yes with no comment.
[IBM]
On 2017-04-28 IBM voted No with the following comment:
IBMの投票は、現時点ではPublic Reviewステージを通過して、Proposed Final Draftステージに進むまでには至っていないという我々の立場を反映しています。JSR 376 Expert GroupおよびExpert Group以外の面々は、現在の仕様のPublic Review Draftについて、数多くの合理的な問題と懸案事項をいくつか提起しており、さらなる議論と解決が必要と考えています。我々は、メーリングリストに記載された問題に対処するため、Expert Groupの全メンバー間で継続して作業することを提唱します。IBMは、この仕様が次のステップに進む前に、Expert Group全体のコンセンサスをより深めたいと考えています。
[Intel]
On 2017-04-26 Intel Corp. voted Yes with no comment.
[NXP Semiconductors]
On 2017-04-26 NXP Semiconductors voted Yes with no comment.
[Keil, Werner]
On 2017-05-08 Keil, Werner voted No with the following comment:
IBMやその他のExpert GroupメンバーがNoを投票したその理由について理解しており、（例えばOSGiコミュニティや多数の人が使っているMavenやGradle、Antといったビルドシステムのコントリビュータから）多くの類似した懸念を聞いてきました。彼らが考えている懸念のほとんどに対し、未だにExpert GroupやSpec Leadから回答がないため、現時点ではこのJSRは時期尚早であると考えます。
[Hazelcast]
On 2017-05-03 Hazelcast voted No with the following comment:
我々は、Expert Group内部のコンセンサスが欠如していることは危険な兆候であり、すべての問題に対し、道筋が明確に示されたわけでもなければ、単一の観点から解決済みとなったわけでもないと考えています。 全体として、コミュニティと共に数多くの課題に対処したことで、状況はここ数ヶ月ですばらしい進歩を遂げたと認識していますが、Public Review Ballotに至るにはまだ早いと思われます。
さらに、人気のあるビルドツールの問題は、まだ解決していないように思います。 Executive Comittee（の役割）は、Javaエコシステムが害を受けないようにすることであり、現状では、JSR376はそのような準備ができているとは思えません。
[Red Hat]
On 2017-05-03 Red Hat voted No with the following comment:
Red HatはこのJSRに対してNOを投じています。Red Hatのミドルウェアチームやその他のExecutive CommitteeメンバーやJavaコミュニティのメンバーがパブリックかつ詳細に懸念点を言及しています。
[Goldman Sachs & Co.]
On 2017-05-05 Goldman Sachs & Co. voted Yes with no comment.
[Software AG]
On 2017-05-07 Software AG voted No with the following comment:
Software AGは、Expert Groupメンバー間での健全なコンセンサスの欠如を懸念しています。完全に意見が一致したり、未解決の問題をなくしたりすることは実現できないと理解してはいますが、より健全なコンセンサスは可能であると考えています。また、このようなコンセンサスにより、結果としてよりすぐれたJavaエコシステムになり、よりスムーズに業界がモジュール化されたJavaの世界に移行すると考えています。
Noを投票してはいますが、Spec LeadがExpert Group内でより健全なコンセンサスを形成するため、JCPプロセスの下で与えられた30日間を利用することを望みます。既存のソフトウェアのモジュール化された世界への移行パスと、既存の確立されたJavaプラクティスおよびビルドシステムとの共存について、特に注意を払っていただきたいと考えています（#ModuleNameInManifest、#CyclicDependences、#AutomaticModuleNames、#AvoidConcealedPackageConflicts、#MultiModuleJARs ）。
将来の投票で、Expert Groupの支持がよ強いDraftに対して「Yes」を投票できることを楽しみにしています。
[Azul Systems, Inc.]
On 2017-05-07 Azul Systems, Inc. voted Yes with no comment.
[MicroDoc]
On 2017-05-08 MicroDoc voted Yes with no comment.
[Gemalto M2M GmbH]
On 2017-05-08 Gemalto M2M GmbH voted Yes with no comment.
[Credit Suisse]
On 2017-05-08 Credit Suisse voted No with the following comment:
Credit SuisseはExecutive CommitteeでJavaテクノロジーの顧客を代表しています。JSR 376については、大きな懸念点が2個（automatic modulesとreflection）あり、これらはこのJSRを簡単に採用することと、潜在的に矛盾するものです。Expert Groupに解決策が提示され、これらの重要なトピックについて合意を得るのにExpert Groupへ時間の猶予を与えることは有益である、と理解しています。
[SAP SE]
On 2017-05-08 SAP SE voted No with the following comment:
Groupのメンバーだけでなく、（そして特に）Spec Lead自身によってこれまで遂行された偉大な成果と作業を十分に認識しています。JPMSはJavaプラットフォームそのものをモジュール化する上でかなり良い具合ではありますが、仕様の最終承認前に対処し合意しなければならないJavaプラットフォーム外のライブラリやフレームワークに関し、すりあわせが必要な部分がまだ存在するように思います。
私たちは、OpenJDK内の "Project Jigsaw"という文脈の中で、JPMSのオープンな開発を認識していますが、それと同時に、OpenJDK JEPプロセスとJCP JSRプロセスの緊張が高まることを懸念しています。開発時およびこれまでのところ、JPMS/Jigsawの開発でどれが実装の詳細で、どれが標準仕様なのかが明確ではありませんでした。モジュールやランタイムイメージのバイナリ形式のような機能、jlinkツール、ハッシュやバージョンなどの新しいクラス属性は、標準化されていない実装の詳細の例です。
しかし、私たちが特に心配しているのは、Expert Group内での直接のコミュニケーションが不足していることです。このJSRが承認に必要な3分の2の過半数で承認されない場合には、Expert GroupおよびSpec Leadが定期的なミーティングのためにこの増えた30日を使い、残存する問題を整理し、新しい、より多くの持続可能で将来を見据えた提案を作成することを期待します。すべての懸念を救済することは不可能であると認識していますが、この数日でよい妥協（例えば、automatic modulesの問題など）がまだ可能であることが明確に示されたと思っています。そして、猶予期間を使って、再考投票に向けてよりよい仕様を提出することができると自信を持っています。
最後に、全てのメンバーおよびSpec Leadがテーブルに戻り、ブログとオープンレターでお互いを責めるのではなく、直接お互いにコミュニケーションを取ることを切に願います。
[London Java Community]
On 2017-05-08 London Java Community voted No with the following comment:
SAPからのコメントの通り、私たちは、Expert Groupメンバーだけでなく、（特に）Spec Lead自身によってこれまで成されてきたすばらしい成果を十分に認識しています。
LJCは、投票期間の開始時に提出された仕様に対し、Noと投票しています。14日間の投票期間中、#AutomaticModuleNamesのような非常に困難な問題についてはSpec LeadとExpert Groupによって合意に達し、大きく前進しました。しかし、いくつかの問題はまだ話し合いが行われており、エコシステムが、十分な深さ、十分な時間を費やして最新の仕様に基づいて実装したりテストする上で、新しいデザインの議論に十分な時間を費やしているとは言えません。具体的には、Eclipse ejcコンパイラやMavenにおける最新のAutomatic Module Namingのデザインなどです。
必要に応じて、Expert Group（およびエコシステム）がこれらの難しい仕様項目の議論や実装、テストを行うために少々時間を使ったバージョンで、30日以内にYesと投票できることを非常に楽しみにしています。確かに最後の14日間は、真逆の視点から始まったにも関わらず合意に達することができましたが、最後の障害を解決するためにもうちょっと時間が必要と考えています。必要であれば、30日以内にYesを投票できることを楽しみにしています。
[V2COM]
On 2017-05-08 V2COM voted Yes with the following comment:
V2COMは他のExecutive Committeeの懸念を共有していますが、全ての主要な懸念はこの投票と次回の投票の間に対処できると信じています。
[Grimstad, Ivar]
On 2017-05-08 Grimstad, Ivar voted No with the following comment:
投票期間の開始時に提出された仕様に対しNoと投票しています。14日間の投票期間中の議論はすばらしいものであり、この期間にSpec LeadとExpert Groupが成した進捗、特に、直近のAutomatic Module Namingに関する提案はすばらしいと思っています。
継続的な議論とこれらの変更が仕様に組み込まれ、再検討投票でYesと投票できることを楽しみにしています。
[Twitter, Inc.]
On 2017-05-08 Twitter, Inc. voted No with the following comment:
Java 9におけるJava Platform Module System（JPMS）の導入を、Javaプラットフォームへの望ましくて価値のある追加と認識しており、誕生後20年たってから、Javaのような成熟して広く使われている言語をモジュール化するという、非常に困難な作業に対しありがたく思っています。JSR Lead、Expert Group 、そして尽力された全ての人、そして実現するためのあらゆる努力に感謝しています。
私たちの主な関心事は、このJSRはJava開発者にとって破壊的であると判明し、その上究極的にはそのようなシステムに期待される利点を提供しない可能性が高い、という点です。このためにこの重要な技術が広範な採用されるまでに時間がかかる可能性を心配しています。JPMSが本来の目的をより包括的に達成するならば（特に、エクスポート対象外のPackage名の衝突は "non-interference（非干渉）"と "strong encapsulation（強力なカプセル化）"という目標とは相容れません）、Java開発者が今日抱える現実の課題（例えば、エクスポート対象外パッケージとして隠すことによって同じパッケージの複数のコピーを扱う）に対処できるでしょう。これにより、より多くの開発者がモジュール開発を迅速に採用できるようになります。
最後に、JSR LeadとExpert Groupメンバーの幅広いコンセンサスがこういった重要なJSRにとっては必要であると考えています。
[SouJava]
On 2017-05-08 SouJava voted Yes with the following comment:
SouJavaはJava Platform Module System仕様に対しYESを投票します。
他のメンバーのコメントの通り、チームによるこの作業に大きな成果があったことには同意します。しかし、Public Reviewに出てきた仕様はExpert Groupが同意しておらず、そのことへの不安によって、SouJava内の議論はNOを投票する方向になりました。
（しかしながら）ここ数週間のSpec Leadの動きの結果、全体的な意見が変わりました。問題解決への努力に感謝しています。
私たちは、Public Reviewに提出された仕様には不足がある、という、London Java Communityやその他の意見に同意します。 Spec Leadが、後に改良される初期リリースに重点を置くべきであることを理解しており、ツールの問題に関するいくつかの妥協を歓迎しています。
しかし、この仕様が独立した実装をサポートしていない場合にはより大きな問題です。独立した実装はJCPの第1の目的であり、状況が変わらない場合には、Yesを投票し続けるつもりはありません。
[Fujitsu Limited]
On 2017-05-08 Fujitsu Limited voted Yes with the following comment:
数多くの懸念はありますが、Expert Groupメンバーが次回の投票までに懸念事項を解決することを願っています。
[Eclipse Foundation, Inc]
On 2017-05-08 Eclipse Foundation, Inc voted No with the following comment:
Eclipse Foundationは、LJC（London Java Community）と同様、「投票開始時に提出された」仕様に「いいえ」と投票しています。Eclipse Foundationは、独立した非依存の実装が動作するように改訂された仕様を期待しています。最近の会話内容は非常に肯定的なものであり、Expoert Groupが正しい方向に向かっていると我々は感じています。しかし、投票を依頼されたDraftには、様々なメーリングリストにおける最近の会話で記載されているように、数多くの重大な欠陥が含まれています。これらの会話を完了して改訂案に含めることができれば、仕様が大幅に改善されると感じています。
[Hewlett Packard Enterprise]
On 2017-05-08 Hewlett Packard Enterprise voted No with the following comment:
Expert GroupやSpec Leadによる進捗は認識しています。ですが、Hewlett Packard Enterpriseは、Expert Groupがフィードバックに対処し、未解決の問題を解決し、アップデートされたDraftを提出できるようにすることを期待します。
[Tomitribe]
On 2017-05-08 Tomitribe voted No with the following comment:
TomitribeがNoを投票したのは、この仕様では実際にJCPプロセスを成功裏に通することが難しいのではないか、との懸念したからです。このJSRを次のステージに移行してFinal Approval Ballotで拒否された場合、Spec LeadとExpert Groupは30日以内にすべての問題を解決するか、仕様をJCPルールに従って永久に葬るかのいずれかを取る必要があります。
過去14日間の進捗状況を賞賛する他の有権者の心情を代弁します。Noを投票することで得た30日間の期間で、完璧な合意を得ることはできないとはいえ、大きな助けになると信じています。事態収拾のための時間です。過去2週間の変更により、最終投票に提示されるものがあまり明確ではないからです。
私たちは、この勢いのために重要な圧力を維持する点で、Exective ComitteeへのフィードバックとExective Comitteeからのフィードバックのための30日の猶予期間を選択したことにポジティブな見方をしています。JSR-299（CDI 1.0）は、Public Review BallotとFinal Approval Ballotの間に9ヶ月もかかった結果、Java EE 5は大幅にリリースが遅れました。ここでも同じことが起こるのは嫌です。 30日の期間はSpec Leadと本質的にExpert Groupに適用され、その後すぐに投票します。
Noの投票は拒絶反応のように見えるかもしれませんが、突き詰めていくと、時間のプレッシャーは引き続きあるものの、JSRから必要と思われるより大きなレベルの合意を得るための、最も指示的な投票であると信じています。
原文はこちら。
https://jcp.org/en/jsr/results?id=5959
[Oracle]
On 2017-04-25 Oracle voted Yes with no comment.
[IBM]
On 2017-04-28 IBM voted No with the following comment:
IBMの投票は、現時点ではPublic Reviewステージを通過して、Proposed Final Draftステージに進むまでには至っていないという我々の立場を反映しています。JSR 376 Expert GroupおよびExpert Group以外の面々は、現在の仕様のPublic Review Draftについて、数多くの合理的な問題と懸案事項をいくつか提起しており、さらなる議論と解決が必要と考えています。我々は、メーリングリストに記載された問題に対処するため、Expert Groupの全メンバー間で継続して作業することを提唱します。IBMは、この仕様が次のステップに進む前に、Expert Group全体のコンセンサスをより深めたいと考えています。
[Intel]
On 2017-04-26 Intel Corp. voted Yes with no comment.
[NXP Semiconductors]
On 2017-04-26 NXP Semiconductors voted Yes with no comment.
[Keil, Werner]
On 2017-05-08 Keil, Werner voted No with the following comment:
IBMやその他のExpert GroupメンバーがNoを投票したその理由について理解しており、（例えばOSGiコミュニティや多数の人が使っているMavenやGradle、Antといったビルドシステムのコントリビュータから）多くの類似した懸念を聞いてきました。彼らが考えている懸念のほとんどに対し、未だにExpert GroupやSpec Leadから回答がないため、現時点ではこのJSRは時期尚早であると考えます。
[Hazelcast]
On 2017-05-03 Hazelcast voted No with the following comment:
我々は、Expert Group内部のコンセンサスが欠如していることは危険な兆候であり、すべての問題に対し、道筋が明確に示されたわけでもなければ、単一の観点から解決済みとなったわけでもないと考えています。 全体として、コミュニティと共に数多くの課題に対処したことで、状況はここ数ヶ月ですばらしい進歩を遂げたと認識していますが、Public Review Ballotに至るにはまだ早いと思われます。
さらに、人気のあるビルドツールの問題は、まだ解決していないように思います。 Executive Comittee（の役割）は、Javaエコシステムが害を受けないようにすることであり、現状では、JSR376はそのような準備ができているとは思えません。
[Red Hat]
On 2017-05-03 Red Hat voted No with the following comment:
Red HatはこのJSRに対してNOを投じています。Red Hatのミドルウェアチームやその他のExecutive CommitteeメンバーやJavaコミュニティのメンバーがパブリックかつ詳細に懸念点を言及しています。
Concerns Regarding Jigsaw(JSR-376, Java Platform Module System)我々はまた、いくつかの懸念事項に対して良い反論を行った自社のOpenJDKチームと話し合った結果、最終的にはNOを投じることが正しい行動であると考えています。以前のExpert Groupの（メーリング）リストでの投票とコメントで、ミドルウェア/SE開発者の視点から、JigsawはJava EEのようなものが使用可能なモジュールシステムという本来の目標を達成していない、との見解を示しました。当初から、Expert Groupの最初の目標が変更され、JVMを完全にモジュール化するために利用されるモジュールシステムに焦点を当てようとしましたが、その結果、アーキテクチャや実装のアプローチが、Java SE開発者やJava EE開発者が使用するためのモジュールシステムたらしめることが困難になったと理解しています。残念なことに、Expert Groupの存続期間中、目標はJava開発者のためのモジュールシステムたらしめるようにスイッチバックしたようですが、以前の実装に関する決定は再検討されなかったか、もしくは変更できなかったようで、その結果、実装はJigsawへの期待に足るものではありませんでした。したがって、現在の実装が広範なJavaコミュニティに対する影響、特に既存のプロジェクトや製品だけでなく、さらにJava EEも含めた影響を懸念しています。私たちは、Expert Groupの（メーリング）リストでいくつかの問題を提起し、これらの事柄のいくつかを影響を最小限にとどめると考えられる方法で是正しようとしましたが、拒否されました。さらに、JVMにとって非常に劇的な一連の変更は、Expert Groupのコンセンサスが不十分であり、Javaコミュニティからの意見を受け取り、議論するオープン性にも欠けていると考えます。もっとあらゆる意見を評価し、同意を得ることに時間をかけすぎるべきではありませんが、（もう少し時間をかけることで）Javaエコシステム全体でがより受け入れられるものになると考えます。
https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical-deficiencies-in-jigsawjsr-376-java-platform-module-system-ec-member-concerns
Jigsaw, EC Member Concerns - An analysis of the Jigsaw technology and its relationship to JPMS (JSR-376)
https://developer.jboss.org/servlet/JiveServlet/download/38-155022/JSR376.pdf
[Goldman Sachs & Co.]
On 2017-05-05 Goldman Sachs & Co. voted Yes with no comment.
[Software AG]
On 2017-05-07 Software AG voted No with the following comment:
Software AGは、Expert Groupメンバー間での健全なコンセンサスの欠如を懸念しています。完全に意見が一致したり、未解決の問題をなくしたりすることは実現できないと理解してはいますが、より健全なコンセンサスは可能であると考えています。また、このようなコンセンサスにより、結果としてよりすぐれたJavaエコシステムになり、よりスムーズに業界がモジュール化されたJavaの世界に移行すると考えています。
Noを投票してはいますが、Spec LeadがExpert Group内でより健全なコンセンサスを形成するため、JCPプロセスの下で与えられた30日間を利用することを望みます。既存のソフトウェアのモジュール化された世界への移行パスと、既存の確立されたJavaプラクティスおよびビルドシステムとの共存について、特に注意を払っていただきたいと考えています（#ModuleNameInManifest、#CyclicDependences、#AutomaticModuleNames、#AvoidConcealedPackageConflicts、#MultiModuleJARs ）。
将来の投票で、Expert Groupの支持がよ強いDraftに対して「Yes」を投票できることを楽しみにしています。
[Azul Systems, Inc.]
On 2017-05-07 Azul Systems, Inc. voted Yes with no comment.
[MicroDoc]
On 2017-05-08 MicroDoc voted Yes with no comment.
[Gemalto M2M GmbH]
On 2017-05-08 Gemalto M2M GmbH voted Yes with no comment.
[Credit Suisse]
On 2017-05-08 Credit Suisse voted No with the following comment:
Credit SuisseはExecutive CommitteeでJavaテクノロジーの顧客を代表しています。JSR 376については、大きな懸念点が2個（automatic modulesとreflection）あり、これらはこのJSRを簡単に採用することと、潜在的に矛盾するものです。Expert Groupに解決策が提示され、これらの重要なトピックについて合意を得るのにExpert Groupへ時間の猶予を与えることは有益である、と理解しています。
[SAP SE]
On 2017-05-08 SAP SE voted No with the following comment:
Groupのメンバーだけでなく、（そして特に）Spec Lead自身によってこれまで遂行された偉大な成果と作業を十分に認識しています。JPMSはJavaプラットフォームそのものをモジュール化する上でかなり良い具合ではありますが、仕様の最終承認前に対処し合意しなければならないJavaプラットフォーム外のライブラリやフレームワークに関し、すりあわせが必要な部分がまだ存在するように思います。
私たちは、OpenJDK内の "Project Jigsaw"という文脈の中で、JPMSのオープンな開発を認識していますが、それと同時に、OpenJDK JEPプロセスとJCP JSRプロセスの緊張が高まることを懸念しています。開発時およびこれまでのところ、JPMS/Jigsawの開発でどれが実装の詳細で、どれが標準仕様なのかが明確ではありませんでした。モジュールやランタイムイメージのバイナリ形式のような機能、jlinkツール、ハッシュやバージョンなどの新しいクラス属性は、標準化されていない実装の詳細の例です。
しかし、私たちが特に心配しているのは、Expert Group内での直接のコミュニケーションが不足していることです。このJSRが承認に必要な3分の2の過半数で承認されない場合には、Expert GroupおよびSpec Leadが定期的なミーティングのためにこの増えた30日を使い、残存する問題を整理し、新しい、より多くの持続可能で将来を見据えた提案を作成することを期待します。すべての懸念を救済することは不可能であると認識していますが、この数日でよい妥協（例えば、automatic modulesの問題など）がまだ可能であることが明確に示されたと思っています。そして、猶予期間を使って、再考投票に向けてよりよい仕様を提出することができると自信を持っています。
最後に、全てのメンバーおよびSpec Leadがテーブルに戻り、ブログとオープンレターでお互いを責めるのではなく、直接お互いにコミュニケーションを取ることを切に願います。
[London Java Community]
On 2017-05-08 London Java Community voted No with the following comment:
SAPからのコメントの通り、私たちは、Expert Groupメンバーだけでなく、（特に）Spec Lead自身によってこれまで成されてきたすばらしい成果を十分に認識しています。
LJCは、投票期間の開始時に提出された仕様に対し、Noと投票しています。14日間の投票期間中、#AutomaticModuleNamesのような非常に困難な問題についてはSpec LeadとExpert Groupによって合意に達し、大きく前進しました。しかし、いくつかの問題はまだ話し合いが行われており、エコシステムが、十分な深さ、十分な時間を費やして最新の仕様に基づいて実装したりテストする上で、新しいデザインの議論に十分な時間を費やしているとは言えません。具体的には、Eclipse ejcコンパイラやMavenにおける最新のAutomatic Module Namingのデザインなどです。
必要に応じて、Expert Group（およびエコシステム）がこれらの難しい仕様項目の議論や実装、テストを行うために少々時間を使ったバージョンで、30日以内にYesと投票できることを非常に楽しみにしています。確かに最後の14日間は、真逆の視点から始まったにも関わらず合意に達することができましたが、最後の障害を解決するためにもうちょっと時間が必要と考えています。必要であれば、30日以内にYesを投票できることを楽しみにしています。
[V2COM]
On 2017-05-08 V2COM voted Yes with the following comment:
V2COMは他のExecutive Committeeの懸念を共有していますが、全ての主要な懸念はこの投票と次回の投票の間に対処できると信じています。
[Grimstad, Ivar]
On 2017-05-08 Grimstad, Ivar voted No with the following comment:
投票期間の開始時に提出された仕様に対しNoと投票しています。14日間の投票期間中の議論はすばらしいものであり、この期間にSpec LeadとExpert Groupが成した進捗、特に、直近のAutomatic Module Namingに関する提案はすばらしいと思っています。
継続的な議論とこれらの変更が仕様に組み込まれ、再検討投票でYesと投票できることを楽しみにしています。
[Twitter, Inc.]
On 2017-05-08 Twitter, Inc. voted No with the following comment:
Java 9におけるJava Platform Module System（JPMS）の導入を、Javaプラットフォームへの望ましくて価値のある追加と認識しており、誕生後20年たってから、Javaのような成熟して広く使われている言語をモジュール化するという、非常に困難な作業に対しありがたく思っています。JSR Lead、Expert Group 、そして尽力された全ての人、そして実現するためのあらゆる努力に感謝しています。
私たちの主な関心事は、このJSRはJava開発者にとって破壊的であると判明し、その上究極的にはそのようなシステムに期待される利点を提供しない可能性が高い、という点です。このためにこの重要な技術が広範な採用されるまでに時間がかかる可能性を心配しています。JPMSが本来の目的をより包括的に達成するならば（特に、エクスポート対象外のPackage名の衝突は "non-interference（非干渉）"と "strong encapsulation（強力なカプセル化）"という目標とは相容れません）、Java開発者が今日抱える現実の課題（例えば、エクスポート対象外パッケージとして隠すことによって同じパッケージの複数のコピーを扱う）に対処できるでしょう。これにより、より多くの開発者がモジュール開発を迅速に採用できるようになります。
最後に、JSR LeadとExpert Groupメンバーの幅広いコンセンサスがこういった重要なJSRにとっては必要であると考えています。
[SouJava]
On 2017-05-08 SouJava voted Yes with the following comment:
SouJavaはJava Platform Module System仕様に対しYESを投票します。
他のメンバーのコメントの通り、チームによるこの作業に大きな成果があったことには同意します。しかし、Public Reviewに出てきた仕様はExpert Groupが同意しておらず、そのことへの不安によって、SouJava内の議論はNOを投票する方向になりました。
（しかしながら）ここ数週間のSpec Leadの動きの結果、全体的な意見が変わりました。問題解決への努力に感謝しています。
私たちは、Public Reviewに提出された仕様には不足がある、という、London Java Communityやその他の意見に同意します。 Spec Leadが、後に改良される初期リリースに重点を置くべきであることを理解しており、ツールの問題に関するいくつかの妥協を歓迎しています。
しかし、この仕様が独立した実装をサポートしていない場合にはより大きな問題です。独立した実装はJCPの第1の目的であり、状況が変わらない場合には、Yesを投票し続けるつもりはありません。
[Fujitsu Limited]
On 2017-05-08 Fujitsu Limited voted Yes with the following comment:
数多くの懸念はありますが、Expert Groupメンバーが次回の投票までに懸念事項を解決することを願っています。
[Eclipse Foundation, Inc]
On 2017-05-08 Eclipse Foundation, Inc voted No with the following comment:
Eclipse Foundationは、LJC（London Java Community）と同様、「投票開始時に提出された」仕様に「いいえ」と投票しています。Eclipse Foundationは、独立した非依存の実装が動作するように改訂された仕様を期待しています。最近の会話内容は非常に肯定的なものであり、Expoert Groupが正しい方向に向かっていると我々は感じています。しかし、投票を依頼されたDraftには、様々なメーリングリストにおける最近の会話で記載されているように、数多くの重大な欠陥が含まれています。これらの会話を完了して改訂案に含めることができれば、仕様が大幅に改善されると感じています。
[Hewlett Packard Enterprise]
On 2017-05-08 Hewlett Packard Enterprise voted No with the following comment:
Expert GroupやSpec Leadによる進捗は認識しています。ですが、Hewlett Packard Enterpriseは、Expert Groupがフィードバックに対処し、未解決の問題を解決し、アップデートされたDraftを提出できるようにすることを期待します。
[Tomitribe]
On 2017-05-08 Tomitribe voted No with the following comment:
TomitribeがNoを投票したのは、この仕様では実際にJCPプロセスを成功裏に通することが難しいのではないか、との懸念したからです。このJSRを次のステージに移行してFinal Approval Ballotで拒否された場合、Spec LeadとExpert Groupは30日以内にすべての問題を解決するか、仕様をJCPルールに従って永久に葬るかのいずれかを取る必要があります。
過去14日間の進捗状況を賞賛する他の有権者の心情を代弁します。Noを投票することで得た30日間の期間で、完璧な合意を得ることはできないとはいえ、大きな助けになると信じています。事態収拾のための時間です。過去2週間の変更により、最終投票に提示されるものがあまり明確ではないからです。
私たちは、この勢いのために重要な圧力を維持する点で、Exective ComitteeへのフィードバックとExective Comitteeからのフィードバックのための30日の猶予期間を選択したことにポジティブな見方をしています。JSR-299（CDI 1.0）は、Public Review BallotとFinal Approval Ballotの間に9ヶ月もかかった結果、Java EE 5は大幅にリリースが遅れました。ここでも同じことが起こるのは嫌です。 30日の期間はSpec Leadと本質的にExpert Groupに適用され、その後すぐに投票します。
Noの投票は拒絶反応のように見えるかもしれませんが、突き詰めていくと、時間のプレッシャーは引き続きあるものの、JSRから必要と思われるより大きなレベルの合意を得るための、最も指示的な投票であると信じています。