Java 7コンパイルされたコードをJava 8にアップグレードすることに利点はありますか？
Java 7を使用して記述された古いアプリケーションがあります。Java 8 JREで正常に動作します。 Java 8の機能を利用するためにコードを書き直すつもりはありません。コンパイルされたコードを最新のJava 8 JDKにアップグレードすることに技術的な利点はありますか？
明確にするために、コードは現在Java 7でコンパイルされており、すでに最新のJava 8 JREで実行されています。 Java 8ランタイムの改善から既に恩恵を受けるはずです。この質問は、バージョン8でコンパイルし、Java 8コンパイル済みバイトコードで実行することで利点が得られるかどうかです。
また、開発者の生産性などの非技術的な利点については関係ありません。これらは重要だと思いますが、この質問のポイントではありません。開発チームがいない本番用コードを求めています。純粋にメンテナンスモードです。
私が質問を正しく理解していれば、Java 8でJava 7よりもjavacによって生成されたバイトコードが「より良い」かどうかを知りたいと思うでしょう。
答えはおそらくそうではなく、コンパイラのバグを常に修正しているため、バイトコードがより効率的になる場合があります。ただし、Java 8のこれらの修正による大幅な高速化は見られませんが、 changelog はバージョン間の2つの大きな変更のみをリストします。
OracleのWebサイトはひどく、バージョン間のjavacに関連するバグ修正のリストを取得できないようですが、 OpenJDKの完全なものではありません です。私が見つけることができるものの大半は、エラーの修正です。したがって、Java 8に更新することにより、javacがJLSにより正確に追従するため、コンパイルできなくなる可能性があり、バイトコードの「改善」はほとんどまたはまったくありません。
主な利点は、Java 8に最新のバグ修正があり、Java 7が公開されていないことです。
また、Java 8 JVMでコードを実行する場合は、Javaの1つのバージョンのみをインストールすることもできます。
Java 8はより高速である可能性があり、G1などの新機能のサポートが向上しています。ただし、ユースケースでは処理が遅くなる可能性があるため、知る唯一の方法はテストすることです。
コンパイルされたコードを最新のJava 8 JDKにアップグレードすることに技術的な利点はありますか？
Java 7コードをJava 8コンパイラで再コンパイルすることに利点があるかどうかを尋ねる場合、答えは次のとおりです。ほとんど何も。
唯一の微妙な違いは、Java APIにわずかな違いがあることです。したがって、Java 8コンパイラーはJava 7
その他の小さな違いは、ファイルの先頭にあるマジックナンバー、おそらく定数プールの順序です。バイトコードは基本的に同じです。ラムダ用に追加されたinvokedynamicのサポートもJava 7に存在していましたが、そのようには使用されませんでした。
awarenessを作成すると役立ちます。
Java8に切り替えると、javacによって追加の警告が発行される場合があります。例：type inferenceは、Java8で大幅に改善されました。そして、それはあなたの現在のコードベースで@SuppressWarningsアノテーションの必要性を排除することができます（そして、そのようなアノテーションがもはや必要でないとき、コンパイラはそれについて警告します）。
そのため、今日コードベースを変更するつもりがない場合でも、Java8に切り替えるとそのようなことがわかります。知識を増やすことは、十分な情報に基づいた意思決定に役立ちます。
一方：
- ここでは、Java8がJava7コードのコンパイルを拒否した（まれな）状況についていくつかの質問を見ました。そのため、Java8に切り替えると、この種の問題に遭遇する（最小限の）リスクも伴います。
- また、コードベースtodayに触れるつもりがない場合でも、後で気が変わる可能性があります。そして、注意を怠ると、Java8の機能を利用する可能性があります。どのcouldは「フィールドの更新」を複雑にします。 two維持するソースコードのバージョンがあるように！
- 次に、顧客がJava7 jreを使用して製品を実行している場合。あなたが彼らに与えるバイナリ修正に本当に注意しなければなりません。このようなセットアップがあります。誤って1つのJava8でコンパイルされたクラスをJava7駆動のテストシステムに配置したため、時間を無駄にしました。開発者とテスト/顧客のセットアップがすべてJava7の場合、それは単純に起こりえません。
簡単に言えば、いくつかの微妙な利点と特定のリスクがあります（リスクの重要性は主に全体的なセットアップに依存します）。
私はこれらの事実を少なくともにします。
1）HashMap内部（jdk-8では高速です）
2）多くのバグが修正され、mightが透過的になり（実行時最適化）、実際に何もしなくてもコードがより速く、より良くなります。
3）G1ガベージコレクター
編集
技術的な観点からは、これはAhead of Time Compilationまたはコンパイラーがコードをさらに分析することで改善する可能性があることに似ています。私の知る限り、そのようなことはJava 8コンパイラでは行われません。
開発者の観点から-たくさんあります。生産性の向上は私にとって最も重要なものです。
編集2
2番目のクエリに一致する2つのポイントのみを知っています。
-パラメーター
メソッドのパラメーター名を保持します。
-プロフィール
フットプリントを小さくするためにCompact Profile Optionと呼ばれます。