http://mreinhold.org/blog/secure-the-train
Webブラウザ内で実行するJavaに関連するセキュリティの脆弱性が最近世間の注目を集めており、Oracleでは一連のCritical Patch Update（最新のCritical Patch Updateは今週はじめにリリース）でこうした問題に対応するためリソースを投入してきました。また、開発プロセスを見直し、新しいコードに対する精査のレベルを上げ、新しい脆弱性が入らないように改善しています。
Java SE 7 Update 21 Release and moreJavaプラットフォームのセキュリティを維持することは新機能開発よりも優先されるもので、こうした労力のために必然的にエンジニアはJava 8の開発のための時間が少なくなってきました。もともと1月をFeature-Completeターゲット（機能の完成目標）としていたのに、ある機能がMilestone 6(M6)に間に合わなかった理由の一つがこれです。
https://blogs.oracle.com/java/entry/java_se_7_update_21
http://orablogs-jp.blogspot.jp/2013/04/java-se-7-update-21-release-and-more.html
JDK 8 M6 status, and extending M7今後、Oracleは、ペースを速めてセキュリティ問題を修正し続け、Javaのセキュリティモデルを強化し、新しいセキュリティ機能を導入することに尽力します。この作業には、多くのエンジニアの作業が必要で、Java 8から機能を落としたり、この段階でリリースの範囲を削減したりしても賄いきれません。
http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-February/002066.html
セキュリティにフォーカスするため、Java 8のスケジュール（9月上旬にGA版をリリース）はもはや達成できません。
JDK8
http://openjdk.java.net/projects/jdk8/
Status
以前書いたように、M6に間に合わなかった最も重要な作業はProject Lambdaという、このリリースの唯一の前に進める機能に関係しています。昨年末にLambdaのために言語とVMの変更を統合しましたが、すべての関係する可動部品とセキュリティの仕事の間にはstream APIと関連するコアライブラリの機能強化を仕上げるのに予想よりもちょっと時間がかかりました（JEP107と109）。現状では最善でも5月上旬までにこの作業が終了できる、つまり予定よりも3ヶ月遅れとみています。JEP 107: Bulk Data Operations for CollectionsM6に間に合わなかった別の機能はリリースのドライバではありませんので、理論的にはリリースからこうした機能を落とすことも可能ですが、Lambdaにもっと時間が必要な場合、それをしても意味がありません。
http://openjdk.java.net/jeps/107
JEP 109: Enhance Core Libraries with Lambda
http://openjdk.java.net/jeps/109
Alternatives
では、どうしたらいいでしょう？多くのオプションがありますが、それらのいくつかを見てみましょう。9月上旬のGAリリースという、現在のスケジュールを維持するために、リリースからLambdaを落とすLambdaを削除すると、残りの機能は面白いけれども全体として、あまり魅力的ではありません。そんなわけで、今年Lambdaを落としてリリースしても、幅広く支持されないでしょう。これまでに提案した2年というサイクルを維持する場合、Lambda自体は2016年までご利用いただけないませんし、誰もそんなに長く待てないと思っています。
Lambdaは残すが、フィードバックやテストの時間を減らしてスケジュールを守る品質を犠牲にしてスケジュールを守るならば、確実に過去の月並みな間違いを繰り返すことになるでしょう。これらの機能もしくはプラットフォーム全体が別の新しいものに置き換わるまで、数百万もの開発者が何年も自分たちの欠陥を回避しなければならない、と不完全な言語への変更とAPIの設計を仮想の石碑に刻むことになるでしょう。
1年以上遅らせて、以前リリースから落としたProject Jigsawを取り込むLambdaほぼ完成しているので、リリースを遅らせることは理にかなっていないと思っています。まして、Jigsawを仕上げるとおそらく1年以上の遅延になるでしょう。それは、OracleのJigsawチームの主要メンバーがセキュリティの問題に多くの時間を費やしているという、以前お伝えしたような理由のためです。
Hold the train
これが一番ましなオプションかな、と思っています。Lambdaが完成するようにスケジュールを遅らせ、徹底的にレビューおよびテストした後にリリースする我々は5月上旬までに残りの設計や開発の仕事を終えることができるならば、夏にビルドのテストおよび安定化が可能で、しっかりしたDeveloper Previewリリースを9月上旬にリリースできるはずです。
Java 8の新しいGAの日を決めるためにはもう少し計画策定が必要ですが、2014年の第1四半期にリリースできるんじゃないかな、と思っています。
これはつまり、現在のGA日である9月初旬から3ヶ月以上遅れるということです。この時点で、11月にGAリリースを準備できていることを確信していませんし、経験上、12月に主要なソフトウェアリリースを出荷しようとするのはほとんどの場合あまりよろしくないので、GAの日付を第一四半期としています。
このオプションは、Java 8のたくさんの新機能のための門戸を開かないでしょうし、既存の機能の範囲を際限なく拡大することもできないでしょう。選ばれた少数の追加機能（特にセキュリティに関連する分野）を追加する可能性がありますが、一般的には、この時間を使って、すでにできあがっている機能を安定化し磨き上げ、チューニングするので、新しい機能を追加しないでしょう。以前後者の道を選択してきましたが、長くひどいものです。
J2SE 1.2 (December 8, 1998)これが最善のコースなのでしょうか。代替案よりはましだと思っていますが、提案を待っています。その間に、Java SE 8 Expert GroupおよびJDK8プロジェクトでの参照実装のコントリビュータ－に同じ質問をするつもりです。
http://en.wikipedia.org/wiki/Java_version_history#J2SE_1.2_.28December_8.2C_1998.29
Java SE 8 Platform Umbrella JSR (337)
http://openjdk.java.net/projects/jdk8/spec/
Features vs. schedule
以前このように主張しました。「定期的かつリズミカルなリリースプロセスと緩く結合されているだけの、イノベーションの連続パイプラインとしてJava開発プロセスを構築することが最善だ」主要な機能が当初予定していた列車に間に合わない場合、残念ではあるにせよ、それが世界の終わりではないですし、次の列車が到来するわけで、しかもその列車（リリース日）は予想された時間に出発するわけです。
Project Jigsaw: Late for the train: The Q&Aこれはよいポリシーだと今も思っていますが、このケースでこのポリシーを厳守すると、上記の最初のオプション、つまりLambdaをリリースから落としてスケジュールを守るというオプションを取ることを意味しますが、これを誰もが実際に望んでいることかというと非常に疑わしいと思っています。したがって、この一般的なポリシーに対する例外はありだと思っています。
http://mreinhold.org/blog/late-for-the-train
上記の提案を採用いただけるならば、我々がコミットしたブラウザ関連のセキュリティ対策を完了した後、通常の2年間のリリースサイクルを再開して、2014年はじめにJava8、2016年はじめにJava9をリリースすることができるはずです。
0 件のコメント:
コメントを投稿