Java 7コンパイル済みコードをJava 8にアップグレードするメリットはありますか?


127

Java 7を使用して作成された古いアプリケーションがあります。Java8 JREで正常に実行されます。Java 8の機能を利用するためにコードを書き直すつもりはありません。コンパイルされたコードを最新のJava 8 JDKにアップグレードすることに技術的なメリットはありますか?

明確にするために、コードは現在Java 7でコンパイルされており、最新のJava 8 JREですでに実行されています。Java 8ランタイムの改善によるメリットがすでに得られているはずです。この質問は、バージョン8でコンパイルし、Java 8コンパイル済みバイトコードで実行することにより、どのような利点が得られるかということです。


また、開発者の生産性などの技術的ではないメリットについても心配していません。これらは重要だと思いますが、この質問の要点ではありません。開発チームのいない本番用コードを求めています。純粋にメンテナンスモードです。


2
ただ明確にします。コードはすでに最新の1.8 JREで実行されているため、最新のJava 8のバグ修正とランタイムパフォーマンスの改善(私の知る限り)がすべて含まれています。
g8torPaul 2017

4
これはおそらく、コンパイラによって出力されるバイトコードについての質問です。たぶんあなたの質問でそれをもう少し明確にしてください。
M Platvoet 2017

2
開発者の生産性の向上はここでは関係ありませんか?
ミックニーモニック2017

7
「コードを書き直すつもりがない」とはどういうわけか、信じられないほどはっきりしない。
eldo

3
これは幾分関連してもよい。stackoverflow.com/questions/21732290/...
アルノー

回答:


82

私が質問を正しく理解している場合、によって生成されたバイトコードjavacがJava 7よりもJava 8の方が「優れている」かどうかを知りたいでしょう。

答えはおそらく違うでしょう。彼らは常にコンパイラのバグを修正しており、時にはより効率的なバイトコードにつながります。しかし、私が見る限り、Java 8のこれらの修正による大幅な高速化は見られません。変更ログには、バージョン間の2つの主要な変更のみが記載されています。

オラクルのウェブサイトはひどいものでありjavac、バージョン間のバグ修正のリストを取得できないようですが、OpenJDKからの完全なものではありません。私が見つけることができるものの大部分はエラーの修正です。したがって、Java 8に更新することによりjavac、JLS をより正確にたどるためにコンパイルできなくなる可能性があり、バイトコードに対する「改善」はほとんどまたはまったくありません。


4
おかげで、私はOpenJDKのリストの一部を確認しましたが、javacのパフォーマンスが向上したように見えることを除いて、特に目立つものはありません。OracleのWebサイトでJavaのバージョン間で修正/機能の妥当な検索を行うことはほぼ不可能であることに同意します。各バージョンのリリースノートの形式は一貫していません。私の
直感は

1
Javaの8でのみ利用できますあなたが使用しようとしている場合を除きg8torPaul @、例えばlamdbas /ストリーム
ピーターLawrey

21

主な利点は、Java 7では最新のバグが修正されていないため、Java 8では最新のバグが修正されていることです。

また、Java 8 JVMでコードを実行する場合は、Javaのバージョンを1つだけインストールすることもできます。

Java 8の方が高速で、G1などの新機能のサポートが向上しています。ただし、ユースケースによっては遅くなる可能性があるため、テストすることが唯一の方法です。

コンパイルされたコードを最新のJava 8 JDKにアップグレードすることに技術的なメリットはありますか?

Java 8コンパイラでJava 7コードを再コンパイルすることに利点があるかどうかを尋ねている場合、答えは次のとおりです。ほとんど何もない。

唯一の微妙な違いは、Java APIに小さな違いがあったため、Java 8コンパイラーがJava 7

その他のマイナーな違いは、ファイルの先頭にあるマジック番号であり、定数プールの順序である場合があります。バイトコードは基本的に同じinvokedynamicです。ラムダ用に追加されたサポートでさえJava 7に存在しましたが、そのようには使用されませんでした。


8
私が間違っている場合は修正してください。ただし、OPはJava 8でコードを再コンパイルすることを求めますが、答えはJava 8を使用して実行するかどうかです。
tobias_k 2017

5
現在、最新のJava 1.8 JREで実行しています。バグ修正と内部JavaコードはすべてJREによって提供されます。これが私の質問を解決するとは思いません。
g8torPaul 2017

16
これは単に質問に答えません。「ほとんどない」場合は、違いを明確にしてください。そうでなければ、それは推測にすぎません
M Platvoet 2017

1
@ピーター・ローリー、あなたは「..答えは、ほとんど何もない」と言っています。それを裏付ける証拠はありますか?ところで、私はあなたに同意する傾向があります。
g8torPaul 2017

2
@ g8torPaul Java 8はJava 7との下位互換性があるように設計されており、Java 8の機能を使用していない場合は、ほぼ同じバイトコードを生成するはずです。
Peter Lawrey 2017

21

それは意識を作ることによって助けることができます。

Java8に切り替えると、javacによって追加の警告が出力される場合があります。例:Java8では、型推論が大幅に改善されています。これにより、現在のコードベースで@SuppressWarningsアノテーションが不要になる可能性があります(そのようなアノテーションが不要になると、コンパイラーは警告を出します)。

そのため、今日コードベースを変更するつもりがない場合でも、Java8に切り替えるとそのようなことを知ることができます。知識を増やすことは、情報に基づいた決定を行うのに役立ちます。

一方:

  • ここでは、Java8がJava7コードのコンパイルを拒否した(まれな)状況についていくつか質問をしました。したがって、Java8に切り替えると、そのような問題が発生する(最小限の)リスクも伴います。
  • そして、今日コードベースに触れるつもりがない場合でも、後で気が変わる可能性があります。そして、注意を払っていないときは、Java8の機能を利用するかもしれません。「フィールドの更新」複雑になる可能性があります。あなたは今2つ持っているので維持するソースコードのバージョンになります。
  • 次に、java7 jreを使用して製品を実行している顧客がいる場合。あなたはそれらに与えるバイナリ修正に本当に注意しなければなりません。このような設定があります。また、Java8でコンパイルされた単一のクラスをJava7駆動のテストシステムに誤って配置してしまったため、何度も時間を無駄にしています。開発者とテスト/顧客の設定がすべてJava7の場合、それはまったく起こり得ません。

簡単に言えば、いくつかの微妙な利点と特定のリスクがあります(リスクの重要性は主に全体的な設定に依存します)。


2
そのようなまれな「Java8がJava7のコンパイルを拒否した」問題の一例:stackoverflow.com/q/41590024/2513200(Oracleコンパイラの既知の問題はJava 8のみに影響しますが、7または9には影響しません)
Hulk

8

私は少なくともこれらの事実のためやります。

1)HashMapの内部(jdk-8では高速です)

2)実際には何もしなくてもコードをより速くより良くする(ランタイム最適化)ために透過的である可能性がある多くのバグが修正されました。

3)G1ガベージコレクター

編集

技術的な観点から見ると、これはAhead of Time Compilationと関係があるように思えますと関連しているように思えるか、コードをさらに分析することでコンパイラーが改善する可能性があるものです。私が知る限り、そのようなことはJava 8コンパイラでは行われません。

開発者の観点から-たくさんあります。生産性の向上は私にとって最も重要なものです。

編集2

2つ目のクエリに一致するポイントは2つしかわかりません。

-パラメーター

メソッドのパラメーター名を保持します。

-プロフィール

フットプリントを小さくするためにコンパクトプロファイルオプションと呼ばれます。


26
しかし、Java 8で実行するだけで、すでにこれらの利点が得られるのではないでしょうか。本当の質問は、「Java 7で同等のものよりもうまく機能する何かをJava 8で書いてもいいですか」のようです。
Jorn Vernee、2017

8
現在、最新のJava 1.8 JREで実行しています。バグ修正と内部JavaコードはすべてJREによって提供されます。ガベージコレクターもJREの一部です。これが私の質問を解決するとは思いません。
g8torPaul 2017

8
@JornVernee OPは、彼は何も書き直したくないと明確に言ったので、質問は、私が理解しているように、「Java 8コンパイラーがJava 7コンパイラーができないトリックを実行できるか」に
似て

2
@JornVernee問題は、Java 7で記述され、Java 8でコンパイルされたコードの実行がJava 7でコンパイルされたコードよりも優れている場合
EarlGrey

6
質問には答えず、単に改善されていないと推測します。
M Platvoet 2017

-1

アプリケーションを再コンパイルする理由が他にない場合は、受け入れられた回答に記載されているように、それほど大きな違いはないでしょう。

ただし、一度だけ再コンパイルする必要がある場合は、次の点を考慮してください。

  • アプリケーションのソースコードはJava 7と互換性があり、おそらく8も互換性があります。
  • コードがJava 8でコンパイルされない場合は、Java 7ソース互換モードのJava 8コンパイラー(-source 7javacを使用)でもコンパイルされない可能性があります。
  • 開発者とCIは、Java 8ランタイムに対してユニットテストと統合テストを実行して、本番環境にできるだけ近づける必要があります。ローカルで実行する場合、開発者は同じJava 8ランタイムでアプリケーションを実行する必要もあります。
  • 同じバージョンですべてを行うよりも、JDK 7でコンパイルしてJRE 8で(同じビルドプロセスまたは同じIDEで)実行する方が困難です。
  • JDK 8でコンパイルし、ターゲットランタイムがJava 8 -source 7-source 8場合は、代わりにを使用してもメリットはありません。
  • を使用-source 8すると、開発者がコンパイルとランタイムの両方にJava 8(またはそれ以降)を使用していることが保証されます(適用されるため-target 8)。

結論として、必要がない場合は再コンパイルしないでください。ただし、最初に(コードの変更により)再コンパイルする必要がある場合は、Java 8に切り替えてください。環境の不一致によるバグのリスクを冒さないでください。また、正当な理由なく開発者を制限しないでください。


2番目の箇条書きが正しくありません。あなたの投稿はいくつかの点で自己矛盾しています。
ローン侯爵

@EJP 2番目の箇条書きは私の経験の詳細ですが、JDK 8で-source 7コンパイルするがコンパイルしない例はあります-source 8か?また、コメントはそれほど建設的ではないので、矛盾を示してください…
Didier L
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.