なぜ==演算子文字列値の比較がJavaにならないのですか？

有能なすべてのJavaプログラマーは、==が参照の等価性をチェックするため、==ではなくString.equals（）を使用してストリングを比較する必要があることを知っています。

文字列を扱うとき、ほとんどの場合、参照の等価性ではなく値の等価性をチェックしています。==を使用するだけで文字列値を比較できる言語であれば、より直感的になると思います。

比較として、C＃の==演算子は文字列 sの値が等しいかどうかをチェックします。参照の等価性を本当に確認する必要がある場合は、String.ReferenceEqualsを使用できます。

もう1つの重要な点は、文字列は不変であるため、この機能を許可しても害はありません。

これがJavaで実装されない特別な理由はありますか？

私はそれが単なる一貫性、または「最小限の驚きの原則」だと思います。文字列はオブジェクトであるため、他のオブジェクトと異なる方法で処理された場合は驚くでしょう。

Javaが登場した当時（〜1995年）、String文字列をNULLで終わる配列として表現することに慣れていたほとんどのプログラマーにとって、単に何かのようなものを持っているだけではまったく贅沢でした。Stringの振る舞いは当時のものであり、それは良いことです。動作を後で微妙に変更すると、動作中のプログラムに驚くべき、望ましくない影響を与える可能性があります。

補足として、String.intern()文字列の標準的な（インターン化された）表現を取得するために使用できます==。その後、と比較できます。インターンには時間がかかりますが、その後、比較は非常に高速になります。

追加：一部の回答が示唆するものとは異なり、それは演算子のオーバーロードをサポートすることではありません。+演算子（連結）は、上で動作StringするJavaは、演算子オーバーロードをサポートしていないにもかかわらず、S。コンパイラで特別なケースとして処理され、に解決されStringBuilder.append()ます。同様に、==特別なケースとして処理された可能性があります。

それでは、なぜ特別な場合に驚く+のに、ではないの==でしょうか？そのため、+単純にはありませんコンパイル非に適用された場合String、オブジェクトそれはすぐには明白ですので。の異なる動作は、==それほど明白ではなく、したがって、それがあなたに当たったとき、はるかに驚くでしょう。

Javaの作成者であるジェームズゴスリングは、2000年7月にこのように説明しました。

C ++で多くの人が乱用しているのを見たので、私はかなり個人的な選択として演算子のオーバーロードを省きました。過去5年から6年、オペレーターの過負荷について人々を調査するのに多くの時間を費やしてきました。コミュニティは3つの部分に分かれているので、本当に魅力的です。悪魔の出現; 誰かがリストの挿入に+のように使用しているので、演算子のオーバーロードで何かをやったことがあります。その問題の多くは、合理的にオーバーロードできる演算子が約6個しかないにもかかわらず、人々が定義したい演算子が数千から数百万あるという事実に起因しています。

言語内の一貫性。異なる動作をする演算子を持つことは、プログラマーにとって驚くべきことです。Javaでは、ユーザーが演算子をオーバーロードすることは許可されていません==。そのため、オブジェクト間の意味は、参照の等価性のみです。

Java内：

• 数値型間で、==数値の等価性を比較します
• ブール型間で、==ブールの等価性を比較します
• オブジェクト間で、==参照IDを比較します
  • .equals(Object o)値を比較するために使用

それでおしまい。シンプルなルールで、欲しいものを簡単に特定できます。これはすべてJLSのセクション15.21で説明されています。これは、理解、実装、および理由付けが簡単な3つのサブセクションで構成されています。

のオーバーロード==を許可すると、正確な動作はJLSを見て特定のアイテムに指を当てて「それがどのように機能するか」と言うことができるものではないため、コードの推論が難しくなる可能性があります。の正確な動作は==、ユーザーにとって驚くかもしれません。それを見るたびに、戻ってそれが実際に何を意味するかを確認する必要があります。

Javaは演算子のオーバーロードを許可しないため、ベース定義をオーバーライドできる値の等価性テストを行う方法が必要です。したがって、これらの設計の選択によって義務付けられました。 ==Javaでは、数値型の数値、ブール型のブール等価性、およびその他すべての参照等価性をテストします（.equals(Object o)値の等価性に必要な処理をオーバーライドできます）。

これは「この設計決定の特定の結果のユースケースがある」という問題ではなく、「これはこれらの他のことを促進する設計決定であり、これが結果である」という問題です。

文字列interningは、このような例の1つです。JLS 3.10.5によると、すべての文字列リテラルはインターンされます。他の文字列は、呼び出されるとインターンさ.intern()れます。これ"foo" == "foo"は、文字列リテラルによって占有されるメモリフットプリントを最小化するために行われた設計上の決定の結果です。それを超えて、文字列のインターンはJVMレベルであり、ユーザーに少し公開されますが、圧倒的多数の場合、プログラマーに関係するものではありません（プログラマーのユースケースはそうではありませんでした）この機能を検討する際にデザイナーにとってリストの上位にあったもの）。

人々がいることを指摘する+と、+=文字列のために、オーバーロードされます。しかし、それはここにもそこにもありません。これは、場合した場合のまま==文字列（とのみ文字列）のために意味する値の平等を持ち、1が必要となる異なる参照の等価のための方法を（唯一の文字列に存在していること）。さらに、これはObjectを取り、ある方法で動作し、ユーザーがStringのすべてのメソッドを特別な場合に必要とする別の==方法で動作することを期待するメソッドを不必要に複雑にします。.equals()

==オブジェクトの一貫性のある契約は、参照の等価性のみであり、値の等価性をテストする必要がある.equals(Object o)すべてのオブジェクトに存在するということです。これを複雑にすると、非常に多くのことが複雑になります。

Javaは演算子のオーバーロードをサポートしていません==。つまり、プリミティブ型または参照にのみ適用されます。それ以外の場合は、メソッドの呼び出しが必要です。デザイナーがこれをした理由は、彼らだけが答えることができる質問です。推測しなければならないのは、おそらく演算子のオーバーロードが、追加することに興味がなかった複雑さをもたらすためです。

私はC＃の専門家ではありませんが、その言語の設計者は、すべてのプリミティブがオブジェクトでstructあり、すべてstructがオブジェクトであるように設定しているようです。C＃では演算子のオーバーロードが許可されているため、この配置により、任意のクラスだけStringでなく、任意の演算子で「期待される」方法で動作させることが非常に簡単になります。C ++でも同じことが可能です。

これは他の言語では異なります。

Object Pascal（Delphi / Free Pascal）およびC＃では、文字列を操作するときに参照ではなく値を比較するために、等価演算子が定義されています。

特にPascalでは、文字列はプリミティブ型であり（初期化されていない文字列のためにNullreferenceExceptionを取得するPascalについて本当に好きなことの1つであり、単に刺激的です）、コピーオンライトセマンティクスがあるため、（ほとんどの場合）文字列操作が非常に安い（つまり、マルチメガバイト文字列の連結を開始した場合にのみ顕著です）。

したがって、これはJavaの言語設計上の決定です。彼らが言語を設計したとき、彼らはC ++の方法（Std :: Stringなど）に従って、文字列がオブジェクトであるようにしました。

そのため、理由は簡単に推測でき、演算子をコーディングしないことでコンパイラの文字列への例外が発生します。

Javaでは、演算子のオーバーロードは一切ありません。そのため、比較演算子はプリミティブ型に対してのみオーバーロードされます。

「String」クラスはプリミティブではないため、「==」のオーバーロードはなく、コンピューターのメモリ内のオブジェクトのアドレスを比較するデフォルトを使用します。

よくわかりませんが、Java 7または8では、oracleはコンパイラで例外を認識してstr1 == str2、str1.equals(str2)

Javaは、==一方のオペランドを他方のオペランドに変換できる場合はいつでも演算子が有効であり、そのような変換の結果を未変換のオペランドと比較する必要があるという基本的な規則を守るように設計されているようです。

このルールはJavaに固有のものではありませんが、言語の他のタイプに関連する側面の設計に、広範囲に及ぶ（そして不幸なことに）いくつかの影響があります。それはの動作を指定することであっクリーナーだろう==オペランドの型の特定の組み合わせに関して、およびタイプXとYの組み合わせ禁じるx1==y1とx2==y1意味するものではありませんがx1==x2、しかし、言語はほとんどそれを行うませんが、[その理念の下で、double1 == long1いずれかのかどうかを示す必要がありますdouble1の正確な表現ではないlong1か、コンパイルを拒否します。int1==Integer1禁止する必要がありますが、オブジェクトが特定の値を持つボックス化された整数であるかどうかをテストする便利で効率的な非スロー手段が必要です（ボックス化された整数ではないものとの比較は単にを返す必要がありますfalse）。

==演算子を文字列に適用することに関して、Javaが型Stringとのオペランド間の直接比較を禁止している場合Object、の動作における驚きをかなり回避==できたかもしれませんが、驚くようなことではないそのような比較のために実装できる動作はありません。型で保持される2つの文字列参照が型で保持さObjectれる参照と異なる動作をするStringことは、それらの動作のいずれかが合法的な型の比較と異なることよりも驚くべきことではありません。String1==Object1が合法である場合、それは、の振る舞いString1==String2とObject1==Object2一致String1==Object1する唯一の方法は、それらが互いに一致することであることを意味します。

一般に、2つのオブジェクト参照が同じオブジェクトを指しているかどうかをテストできるようにするには、非常に正当な理由があります。私が書いたことがたくさんありました

Address oldAddress;
Address newAddress;
... populate values ...
if (oldAddress==newAddress)
... etc ...

そのような場合、私はequals関数を持つ場合と持たない場合があります。そうすると、equals関数は両方のオブジェクトの内容全体を比較する可能性があります。多くの場合、単にいくつかの識別子を比較します。「AとBは同じオブジェクトへの参照」であり、「AとBは同じコンテンツを持つ2つの異なるオブジェクト」は、もちろん2つのまったく異なるアイデアです。

おそらく、文字列のような不変オブジェクトの場合、これはそれほど問題ではありません。不変オブジェクトでは、オブジェクトと値は同じものと考える傾向があります。まあ、「私たち」と言うとき、少なくとも「私」を意味します。

Integer three=new Integer(3);
Integer triangle=new Integer(3);
if (three==triangle) ...

もちろんそれはfalseを返しますが、私は誰かがそれが本当だと思っているのを見ることができます。

ただし、==がオブジェクト一般のコンテンツではなく参照ハンドルを比較すると言うと、文字列の特別なケースを作成すると混乱する可能性があります。ここで他の誰かが言ったように、2つのStringオブジェクトのハンドルを比較したい場合はどうでしょうか？文字列に対してのみ行う特別な機能はありますか？

そして何について ...

Object x=new String("foo");
Object y=new String("foo");
if (x==y) ...

それらは2つの異なるオブジェクトであるために偽ですか、それとも内容が等しい文字列であるために真ですか？

そう、私はプログラマーがこれに戸惑うことを理解しています。私はそれを自分でやりました。つまり、myString.equals（ "foo"）の場合はmyString == "foo"の場合に書き込みます。しかし、すべてのオブジェクトの==演算子の意味を再設計する以外には、その対処方法がわかりません。

これは、のために有効な質問でStrings、文字列のため、だけでなく、いくつかの「値」を表す他の不変オブジェクト、例えばのためだけではなくDouble、BigIntegerとさえInetAddress。

==演算子を文字列やその他の値クラスで使用できるようにするために、3つの選択肢があります。

• これらすべての値クラスとその内容を比較する方法についてコンパイラーに知らせてください。java.langパッケージのほんの一握りのクラスであれば、それを検討しますが、それはInetAddressのようなケースをカバーしていません。

• クラスが==比較動作を定義するように、演算子のオーバーロードを許可します。

• パブリックコンストラクターを削除し、プールからインスタンスを返す静的メソッドを使用して、常に同じ値に対して同じインスタンスを返します。メモリリークを回避するには、Java 1.0には存在しなかったプール内のSoftReferencesのようなものが必要です。そして今、互換性を維持するために、String()コンストラクターを削除することはできません。

今日できることは、演算子のオーバーロードを導入することだけです。個人的には、Javaがそのような経路に進むのは嫌です。

私にとって、コードの読みやすさが最も重要であり、Javaプログラマーは、演算子が言語仕様で定義された固定の意味を持っていることを知っていますが、メソッドはいくつかのコードで定義されており、その意味はメソッドのJavadocで調べる必要があります。文字列比較で==演算子を使用できないことを意味する場合でも、その区別を維持したいと思います。

Javaの比較には、私にとって厄介な点が1つしかありません。それは、自動ボックス化と-アンボックス化の効果です。プリミティブ型とラッパー型の区別を隠します。しかし、それらをと比較すると==、それらは非常に異なっています。

    int i=123456;
    Integer j=123456;
    Integer k=123456;
    System.out.println(i==j);  // true or false? Do you know without reading the specs?
    System.out.println(j==k);  // true or false? Do you know without reading the specs?