java - Java は、よりクリーンな言語の利益のために、将来のバージョンで下位互換性を破るべきですか?

Question

プリミティブは保持する価値がありますか?
非推奨のものはすべて削除する必要がありますか？
2 つの GUI フレームワークが必要ですか?
...

score 11 · Accepted Answer

すでに述べたように、API を非推奨にする方法と時期でさえ、非推奨の API を実際に削除することに関するポリシーについては何も述べられていません...

古い JVM (たとえば 1.4) に基づくアプリケーションの数は依然として重要です。その理由の 1 つは、アプリケーションサーバーが新しいバージョンの JVM で自身を検証するのに長い時間がかかるためです...

本番環境で実際に実行されているアプリケーションの数が非常に多いということは、この「下位互換性」ポリシーがすぐに破られることはないということです。

score 7 · Accepted Answer

下位互換性にはいくつかの種類があります。

古いソースコードは新しいコンパイラでコンパイルできますか?

これは、古い構造を新しい構造に変換するツール、または「source 1.6;」のようなもので処理できます。ファイルの先頭にあるディレクティブ。
古いクラスファイルを新しい JVM で実行できますか?

私の世界では、これは完全なショーストッパーです。非常に多くのサードパーティライブラリを使用しているため、それらすべてを同時にアップグレードするのはコストがかかりすぎます。

これは、非推奨のクラスとメソッドを削除しないための推進力でもありますが、程度は低くなります。
古いクラスファイルは、新しいコンパイラでコンパイルされたコードを呼び出すことができますか?

コールバックがあるため、これは #2 の重要な部分です。
新しくコンパイルされたコードは、古いクラスファイルからコードを呼び出すことができますか?

＃2のもう1つの重要な部分。
コードは開発者と実質的に同じに見えますか?

これは、トレーニング、および完全に変換されていない大規模なコードベースの作業にとって重要です。微妙な側面は、混合コードベースで新機能をどれだけ使用できるかということです。これを壊しすぎると、Java++ の代わりに Scala のようなものができてしまいます。

これらすべてのタイプの互換性を維持するために、ジェネリックが追加されました。Java への互換性のない変更は、少なくとも 2、3、4 を保持してJavaとして受け入れられる可能性があると思います。#1 を処理するためのツールも最低限必要です。

score 4 · Accepted Answer

これは、趣味の (Ruby) 実装の少ない (Python) 言語で行うことができますが、世界中で Java で書かれたアプリの数を想像することはできません。freshmeatまたはsourceforgeを確認してください。そして、それはほんの一部です。いいえ、それは良い考えではありません。実際、それはかなりばかげた考えでしょう。

2 つの GUI フレームワークはありません。Swing は AWT に依存し、その基礎として使用します。

score 3 · Accepted Answer

特定の非推奨の機能が削除された場合、私は本当に楽しみます。たとえば、Dateオブジェクトが本当に不変にされた場合、私は非常に満足します。現状では、不変のクラスを作成している場合、たとえば、日付が不変であると想定することはできず、防御的にコピーする必要があります。また、ハッシュマップのキーとして確実に使用することはできません（どちらの場合も、他のコードメソッドに非推奨として注釈が付けられているかどうかに関係なく、日付を変更できます）。

新しい言語機能を追加することになると、下位互換性のマントラを完全には理解していません。私の考えでは、前のバージョン用に記述されたコードを後のバージョンで実行するために微調整が必要な場合は、それほど大きな問題ではありません。実際、とにかくこれには前例があります。1.5から1.6の間で、ResultSetインターフェースに追加のメソッドが追加されたため、Java 1.5でコンパイルおよび実行されるコードは、1.6でさえコンパイルされませんでした。

レガシーアプリを考えると、5年間更新されていないアプリケーションが最新バージョンのJVMで完全に実行されることを期待するのは合理的ですか？組織がまだJava1.4とそのために作成されたアプリケーションを使用している場合、Java 7に何が入るのか本当に気になりますか？下位互換性を破ることは、JVMの以前のすべてのバージョンも同様に破られることを意味しません。アプリが以前のバージョンを対象としている場合は、そのバージョンのJVMで問題なく実行できます。

最も重要なことは、時間が経ち、人々がJavaを使用するにつれて、間違いや機能のギャップが明らかになり、それらを修正/実装することは大きな恩恵となるでしょう。不幸なことに以前に起こったことのために言語を改善しようとするときにまっすぐにジャケットを着ていること、そして私の見解では基本的な要件ではありません。

もちろん、アップグレードパスについて考える必要があります。たとえば、intを突然整数に変更するには、すべての人に大量の面倒なコード変更が必要になります（さらに、nullチェックを追加する必要があります）。ただし、下位互換性を損なう可能性のある新機能（クロージャなど）を追加したり、長年廃止されたメソッドを削除したりしても、既存のコードにはほとんど影響しません。（非推奨のメソッドを使用していてタフだった場合は、以前にそれらを削除する必要がありましたが、今は強制されています！）

score 3 · Accepted Answer

互換性の理由から、標準のJavaリリースではそれを行うことができません。現在、実稼働環境には非常に多くのJavaソフトウェアがあるため、すべての問題を取り除く新しいリリースでそれを破ることはできません。

ただし、Sunは「JavaX」リリースを作成して、粗雑なものをすべて削除し、現在は含まれていない優れたAPIをすべて追加できると思います（たとえば、より優れた代替手段を利用できるJava APIの置き換えを含む）。 log4j、そして日付とカレンダーから始めましょう）。このリリースはJavaを置き換えるようには設計されていませんが、新しいソフトウェアプロジェクトのターゲットとして存在する可能性があります。また、言語を修正して、Javaを最新バージョンのC＃などと比較して少し不格好に見える機能を含めることもできると思います。修正または少なくとも追加できるコード移植ツールも作成した場合コードベースのすべての問題領域への「FIXME」..。

確かに、Microsoftは、新しいバージョンの.NETがリリースされたときに、それらを新しいバージョンに移行するという優れた仕事をしています。まだ1.4で実行されているアプリケーションの数と、多くの企業の無気力なJavaバージョンポリシー（.NETの人々に最新かつ最高のものを何とかして使用させて喜んでいるようです）を考えると、Sunはここで完全に失敗しました。マシンに複数のJavaをインストールするのは簡単であることを考えると、企業やソフトウェア会社がより早くアップグレードすることを奨励するために、もっと多くのことを行う必要があると思います。

score 2 · Accepted Answer

下位互換性を破ることは、Javaに対して行うのはばかげたことだと思います。もしそうなら、あなたはそれをJava ++と呼ぶかもしれません、それはもはやJavaではありません。一方、Javaの将来のバージョンでは、構文の単純さなどの機能について動的言語から学習する必要があります。ハードウェアの能力は急速に高まっているため、コンパイル言語の抽象レベルは高くなるはずです。現在のJavaバージョンのいくつかの機能を動的言語と比較すると、不器用で冗長すぎるため、開発の生産性が低下します。C＃は動的言語になりつつあるようですか？

score 2 · Accepted Answer

JVM には多くの優れた代替言語があるため、その理由がまったくわかりません。私はむしろ安定した Java を使いたいと思っています。

score 1 · Accepted Answer

市場シェアの大部分は依然として古い jdk/jre を使用しているため、下位互換性を破ることは実際的ではないと思います。

score 0 · Accepted Answer

Pat が言ったように、最新の JDK バージョンの採用は非常に遅く、多くのアプリケーションは現在 Java の古い (場合によっては非常に古い) バージョンを使用して実行されています。

したがって、下位互換性を保証しないことに本当の利点があるとは思いません。

あなたの提案については、プリミティブを削除することの関心はあまりありません。もちろん、Java 5 以降のオートボクシングがあります。ただし、プリミティブにはまだ関心があります...

score 0 · Accepted Answer

JVMが同じままである場合、互換性を壊すことは理にかなっています。その場合、「新しい」Java は、そこにリストされているような、JVM で実行される新しい別の言語になります。幸いなことに、JVM は言語とバージョン間の相互運用性を保証するように設計されているため、影響は限定的であると思います。

score 0 · Accepted Answer

たとえば、日時などの API を書き直す必要があると思います。現在のバージョンが EOL になった場合は、古い API を削除する必要があります。当社の統計によると、お客様の 99.3 % が Java 6 以降を使用しています。非常に古い API との互換性は必要ありません。ただし、API が削除される場合は、明確な時間枠が必要です。

score 0 · Accepted Answer

言語を適切にオーバーホールするには、フォークの方が適切だと思います。率直に言って、Java のジェネリックの動作方法に腹が立ち始めています。

score 0 · Accepted Answer

私が PHP を離れた理由は、メジャーバージョンアップグレード間で API や利用可能な機能が変更されたためです。本当の問題は、古いスクリプトの場合、PHP が互換モードで実行できないことです。コードのアップグレードを強制されたくありません。

Javaは同じ場所にあります。新しいバージョンで古い 1.4 のものを使用できることを確認してください。新しい xyntax を使用するために新しいプログラムを要求することは問題ありませんが、古いものを実行させてください!

score 0 · Accepted Answer

プリミティブに関しては、好むと好まざるとにかかわらず、それらはオブジェクトの基本的なビルディングブロックであるため、常に存在します。もちろん、代わりにラッパークラスを使用することもできますが、それではコンパイラが過負荷になり、ほとんどの場合、最終的にプリミティブに変換されてしまいます。

下位互換性は非常に重要であり、ここで既に述べたように、多くのユーザーがまだ 1.3 および 1.4 コードを実行しています。そうは言っても、レガシーシステムでまだJava 1.0または1.1コードを実行している人がいる場合、すぐにJava 7に移行する可能性は低く、移行したとしても、おそらくコードを書き直す必要があるでしょう。とにかくコード。バージョン >1.2 の非推奨 API は安全に削除できると思います。

下位互換性のもう 1 つの側面はキーワードの追加ですが、これは常に推奨されません。Java 5 では、主要な言語の変更は単一の新しいキーワード「enum」の追加で管理されていましたが、「enum」という名前の変数を含むすべてのコードが非準拠になったため、それでさえ怒りを引き起こしました。私の知る限り、Java 7 での変更は新しいキーワードなしで計画されています (ふぅ!)。

ユヴァル=8-)

score 0 · Accepted Answer

Sun が新しい JDK のアップグレードをすべてのクライアントに押し付けないことを考えると、それは良いことです。古い API を使用している人はアップグレードせず、しばらく古いバージョンの JDK を使用します。

または、おそらく、後方互換モードを実装することによって。

java - Java は、よりクリーンな言語の利益のために、将来のバージョンで下位互換性を破るべきですか?

15 に答える 15

Related

Reference