私は現在、計画されているマイナーなリファクタリング作業を遅らせ、それをJava 7への移行と組み合わせることが理にかなっているかどうかを調査していますが、両方のコードが両方のコードの場合、いくつかのバグの原因を追跡するのが難しくなる可能性があることを少し心配していますとプラットフォームが同時に変更されます。
この移動の利点は、NIO.2を使用してアプリケーション内の多くのIO関連のものをクリーンアップおよび改善できることです。
アプリケーションと関連ライブラリの必要なソースをすべて持っています（変更が必要な場合）。Java7にはわずかな改善しかありません-ほとんどのVMアップデートがすでにJava6にあり、クロージャーやチェーンソーなどの大きな変更がキャンセルされた後-数か月後に使用するには十分に安定しているはずですよね？
私は現在、計画されているマイナーなリファクタリング作業を延期し、それを Java 7 への移行と組み合わせることが理にかなっているのかどうかを調査しています。
まあ、Java 7 のスケジュールについてはまだ多くの不確実性があります。これは、Mark Reinhold (オラクルの Java プラットフォーム グループのチーフ アーキテクト) が彼のブログとOpenJDK メーリング リストで最近説明したとおりです。
最近の JDK 7 の開発スケジュールが、控えめに言っても非現実的であることは、しばらく前から明らかでした。
(...)
現在の最善の見積もりでは、2012 年半ば頃のリリースに間に合うように、計画された作業を完了、テスト、および安定させることができます。
(...)
この「プラン B」の現在の見積もりでは、縮小版の JDK 7 を 2011 年半ばに出荷し、JDK 8 を 2012 年の後半に出荷する可能性があります。
要約する：
Plan A: JDK 7 (as currently defined) Mid 2012 Plan B: JDK 7 (minus Lambda, Jigsaw, and part of Coin) Mid 2011 JDK 8 (Lambda, Jigsaw, the rest of Coin, ++) Late 2012
したがって、最良の場合、Java 7 は 1 年弱で、Java 8 (大きな変更を含む) は 2 年強でリリースされます。最悪の場合、Java 7 は 2 年弱で登場します。
この移行の利点は、NIO.2 を使用してアプリケーション内の多くの IO 関連のものをクリーンアップおよび改善できることです。
後の部分 (NIO.2) では、Java 7 が必要になります。しかし、前の部分 (クリーンアップ) については、特に Java 7 のスケジュールが不確実であることを考えると、すぐに利益が得られるのであれば待つ正当な理由は IMO にはありません。 .
Java 7 にはいくつかのマイナーな改善しかないことを考えると (VM の更新のほとんどが既に Java 6 にあり、Closures や Chainsaw などの大きな変更がキャンセルされた後)、数か月後には十分に安定して使用できるはずですよね?
まず、コミュニティがプラン Bを支持しているように見えても、何も決まっていないので、それに基づいて決定することはありません。第二に、Sun が常に Java バージョン間の優勢な互換性を最大化し、安定したプラットフォームを提供しようとしてきたとしても、将来を予測することはできません :) そして、私はかなり自信を持っていますが、一部の保守的な企業はおそらく少し待つでしょう (選択したシナリオ)。