== 연산자 문자열 값을 비교하지 않은 이유는 무엇입니까?

모든 유능한 Java 프로그래머는 ==가 참조 동등성을 검사하기 때문에 String이 == 대신 String.equals ()를 사용해야한다는 것을 알고 있습니다.

문자열을 다룰 때 대부분의 경우 참조 평등이 아닌 가치 평등을 확인합니다. 언어가 ==를 사용하여 문자열 값을 비교할 수 있으면 더 직관적 인 것처럼 보입니다.

이에 비해 C #의 == 연산자는 문자열 s의 값이 같은지 확인합니다 . 참조 평등을 확인해야하는 경우 String.ReferenceEquals를 사용할 수 있습니다.

또 다른 중요한 점은 문자열을 변경할 수 없으므로이 기능을 허용해도 아무런 해가 없습니다.

이것이 Java로 구현되지 않은 특별한 이유가 있습니까?

나는 그것이 단지 일관성이거나 "최소한 놀람의 원리"라고 생각합니다. 문자열은 객체이므로 다른 객체와 다르게 취급하면 놀랍습니다.

Java가 나왔을 때 (~ 1995), String문자열을 null로 끝나는 배열로 표현하는 데 익숙한 대부분의 프로그래머에게는 마치 사치스러운 것이 없었습니다. String의 행동은 이제 당시의 모습이며, 그것은 좋습니다. 나중에 동작을 미묘하게 변경하면 작업 프로그램에서 바람직하지 않은 놀라운 효과를 얻을 수 있습니다.

부수적으로, 당신은 String.intern()문자열을 정식 (interned) 표현으로 얻는 데 사용할 수 있습니다 ==. 인턴은 시간이 걸리지 만 그 후 비교는 정말 빠릅니다.

추가 : 일부 답변과 달리 운영자 과부하 지원에 관한 것이 아닙니다 . +연산자 (연결)를 작동 String자바 연산자 오버로딩을 지원하지 않는 경우에도 S; 컴파일러에서 특별한 경우로 처리되어로 해결됩니다 StringBuilder.append(). 마찬가지로, ==특별한 경우로 취급 될 수있었습니다.

그렇다면 왜 특별한 경우에 놀랍지 +만 그렇지 ==않습니까? 왜냐하면, 비 객체에 적용될 때 +단순히 컴파일 되지 않기 때문에 String빠르게 알 수 있습니다. 의 다른 행동 은 ==눈에 띄지 않으며 따라서 당신을 때리면 훨씬 더 놀랍습니다.

자바를 만든 제임스 고슬링 (James Gosling )은 2000 년 7 월에 이렇게 설명했다 .

C ++에서 너무 많은 사람들이 그것을 남용하는 것을 보았 기 때문에 연산자 오버로드를 상당히 개인적인 선택으로 제외했습니다. 지난 5-6 년 동안 운영자 과부하에 대해 사람들을 조사하는 데 많은 시간을 보냈으며 커뮤니티가 세 부분으로 나뉘어져 있기 때문에 정말 흥미로워 요. 인구의 약 20-30 %가 운영자 과부하를 악마의 산란; 누군가가 목록 삽입을 위해 +와 같이 사용했기 때문에 실제로 혼란스럽게하는 연산자 오버로드로 무언가를 수행했습니다. 이 문제의 상당수는 현명하게 과부하 할 수있는 약 6 개의 연산자가 있지만 사람들이 정의하고 싶은 수천 또는 수백만의 연산자가 있다는 사실에서 비롯됩니다.

언어 내에서 일관성. 다르게 행동하는 연산자를 갖는 것은 프로그래머에게 놀라운 일이 될 수 있습니다. Java는 사용자가 연산자를 오버로드하는 것을 허용하지 않으므로 참조 평등은 ==객체 간 유일한 합리적인 의미입니다 .

자바 내에서 :

• 숫자 유형 사이에서 숫자 ==동등성을 비교합니다.
• 부울 유형 사이에서 부울 ==동등성을 비교합니다.
• 객체 간 ==참조 ID 비교
  • .equals(Object o)값을 비교하는 데 사용

그게 다야. 간단한 규칙과 원하는 것을 쉽게 식별 할 수 있습니다. 이것은 모두 JLS의 섹션 15.21 에서 다루고 있습니다. 이해하기 쉽고 구현하기 쉬운 세 개의 하위 섹션으로 구성되어 있습니다.

의 오버로드== 를 허용 하면 정확한 동작은 JLS를보고 특정 항목에 손가락을 대고 "작동 방식"이라고 말할 수있는 것이 아닙니다. 코드는 추론하기가 어려워 질 수 있습니다. 의 정확한 행동은 ==사용자에게 놀라운 것일 수 있습니다. 당신이 그것을 볼 때마다, 당신은 돌아가서 그것이 실제로 무엇을 의미하는지 확인해야합니다.

Java는 연산자 오버로드를 허용하지 않으므로 기본 정의를 무시할 수있는 값 평등 테스트를 수행 할 수있는 방법이 필요합니다. 따라서 이러한 설계 선택에 따라 의무화되었습니다. ==Java에서는 숫자 유형에 대한 숫자, 부울 유형에 대한 부울 동등성 및 기타 모든 항목에 대한 참조 동등성을 테스트합니다 ( .equals(Object o)값 평등을 위해 원하는 것을 수행하도록 재정의 할 수 있음).

이것은 "이 디자인 결정의 특정 결과에 대한 유스 케이스가 있습니까?"의 문제가 아니라 "이것은 다른 것들을 용이하게하기위한 디자인 결정입니다. 그 결과입니다."

문자열 interning 이 이에 해당하는 예입니다. JLS 3.10.5 에 따르면 모든 문자열 리터럴이 인터 닝됩니다. 다른 문자열은 하나를 불러 오면 억류됩니다 .intern(). 이는 "foo" == "foo"String 리터럴이 차지하는 메모리 풋 프린트를 최소화하기위한 디자인 결정의 결과입니다. 그 외에도 문자열 인턴은 사용자에게 약간 노출되는 JVM 수준의 것이지만 압도적 인 대다수의 경우 프로그래머와 관련된 것이어서는 안됩니다 (프로그래머의 사용 사례는 그렇지 않았습니다) 이 기능을 고려할 때 디자이너의 목록에서 가장 높은 것).

사람들은 저를 지적 할 것이다 +및 +=문자열에 대한 오버로드. 그러나 그것은 여기도 거기도 없습니다. ==String (및 String 만)에 값 평등 의미가있는 경우 참조 평등을 위해 다른 메소드 (String에만 존재) 가 필요합니다 . 또한 이것은 Object를 취하고 ==한 가지 방식 .equals()으로 행동 하고 사용자가 String에 대한 모든 해당 메소드 를 특수하게 요구하는 다른 행동을 기대 하는 메소드를 불필요하게 복잡하게 만듭니다 .

==객체에 대한 일관된 계약 은 참조 동등성 이며 가치 평등을 테스트 해야하는.equals(Object o) 모든 객체에 대해 존재 한다는 것입니다 . 이것을 복잡하게하면 너무 많은 것들이 복잡해집니다.

Java는 연산자 오버로딩을 지원하지 않으므로 ==기본 유형 또는 참조에만 적용됩니다. 다른 것은 메소드 호출이 필요합니다. 디자이너가 왜 이런 짓을했는지는 그들이 대답 할 수있는 질문입니다. 추측해야한다면 연산자 오버로드로 인해 추가에 관심이 없었던 복잡성이 생길 수 있습니다.

나는 C #의 전문가는 아니지만 해당 언어의 디자이너는 모든 프리미티브가 a struct이고 모든 struct것이 객체가 되도록 언어를 설정 한 것으로 보입니다 . C #은 연산자 오버로딩을 허용하므로 이러한 배열을 통해 클래스뿐만 아니라 모든 클래스가 String연산자와 "예상 된"방식으로 작동 하기가 매우 쉽습니다 . C ++은 같은 것을 허용합니다.

이것은 다른 언어로 다르게 만들어졌습니다.

Object Pascal (Delphi / Free Pascal) 및 C #에서 등식 연산자는 문자열에서 작동 할 때 참조가 아닌 값을 비교하도록 정의됩니다.

특히 Pascal에서 string은 기본 유형입니다 (초기화되지 않은 문자열 때문에 NullreferenceException을 얻는 Pascal에 대해 정말로 좋아하는 것 중 하나는 단순히 자극적입니다). 저렴합니다 (즉, 멀티 메가 바이트 문자열을 연결하기 시작한 후에 만 ​​눈에)니다).

Java의 언어 설계 결정입니다. 그들이 언어를 디자인했을 때 그들은 Std :: String과 같은 C ++ 방식을 따랐으므로 문자열은 객체입니다. 즉, IMHO는 문자열을 원시 (기본)로 만드는 대신 실제 문자열 유형이 부족한 C를 보완하는 해킹입니다.

그래서 이유를 위해서, 나는 그들이 편하게하고 연산자를 코딩하지 않고 컴파일러가 문자열을 예외로 삼았다 고 추측 할 수 있습니다.

Java에서는 연산자 오버로드가 전혀 없으므로 비교 연산자가 기본 유형에 대해서만 오버로드됩니다.

'String'클래스는 기본이 아니므로 '=='에 대한 오버로드가 없으며 컴퓨터 메모리에서 객체의 주소를 비교하는 기본값을 사용합니다.

확실하지 않지만 Java 7 또는 8에서는 오라클이 컴파일러에서 다음 str1 == str2과 같이 인식하도록 예외를 설정했다고 생각합니다.str1.equals(str2)

Java는 ==한 피연산자가 다른 피연산자 유형으로 변환 될 수있을 때마다 연산자가 합법적이어야하고 이러한 변환 결과를 변환되지 않은 피연산자와 비교해야 한다는 기본 규칙을 유지하도록 설계된 것으로 보입니다 .

이 규칙은 Java에만 고유 한 것은 아니지만 언어의 다른 유형 관련 측면 디자인에 광범위한 영향을 미칩니다 (그리고 IMHO 불행한). 의 행동을 지정 청소기했을 ==타입 X와 Y의 조합 피연산자 유형의 특정 조합에 관하여, 그리고 금지 x1==y1와 x2==y1의미하지는 것을 x1==x2하지만, 언어는 거의 철학 아래, [그렇게하지 double1 == long1여부를 표시해야 하나 double1의 정확한 표현 이 아니 long1거나 컴파일을 거부하는 경우;int1==Integer1금지되어야하지만 객체가 특정 값을 가진 박스형 정수인지 테스트하는 편리하고 효율적인 비 투사 방법이 있어야합니다 (박스형 정수가 아닌 다른 것과 비교하면 단순히 반환해야합니다 false)].

인가에 관해서는 ==문자열 연산자를 자바 형식의 피연산자 사이의 직접 비교를 금지 한 경우 String와 Object의 행동, 그것은 꽤 잘 피할 수 놀라움을 ==하지만 놀라운되지 않을 것 같은 비교를 구현할 수있는 어떠한 행동도 없다. 유형으로 유지 된 두 개의 문자열 참조가 유형으로 유지 된 참조 Object와 다르게 작동 String하면 이러한 동작 중 하나가 합법적 인 혼합 유형 비교와 다른 것보다 훨씬 덜 놀랍습니다. String1==Object1합법적 이라면 행동 String1==String2과 행동의 유일한 방법은 서로 Object1==Object2일치하는 String1==Object1것입니다.

일반적으로 두 개의 객체 참조가 동일한 객체를 가리키는 지 테스트 할 수있는 충분한 이유가 있습니다. 내가 쓴 많은 시간을 보냈습니다

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

이 경우 등가 함수가 있거나 없을 수 있습니다. 내가하면 equals 함수는 두 객체의 전체 내용을 비교할 수 있습니다. 종종 일부 식별자를 비교합니다. "A와 B는 같은 객체에 대한 참조"와 "A와 B는 같은 내용을 가진 두 개의 다른 객체"는 물론 두 가지 매우 다른 아이디어입니다.

Strings와 같은 불변의 객체의 경우 이것은 문제가되지 않습니다. 불변의 객체를 사용하면 객체와 값이 같은 것으로 생각하는 경향이 있습니다. 글쎄, "우리"라고 할 때, 나는 적어도 "I"를 의미합니다.

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

물론 그것은 거짓을 반환하지만, 그것이 사실이라고 생각하는 누군가를 볼 수 있습니다.

그러나 ==는 일반적으로 객체의 내용이 아닌 참조 핸들을 비교한다고 말하면 문자열에 특별한 경우를 만드는 것은 혼란 스러울 수 있습니다. 여기 다른 누군가가 말했듯이 두 String 객체의 핸들을 비교하려면 어떻게해야합니까? 문자열에만 사용할 수있는 특별한 기능이 있습니까?

그리고 어쩌면 ...

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

그것들이 두 개의 다른 객체이기 때문에 거짓입니까, 아니면 내용이 동일한 문자열이기 때문에 참입니까?

예, 프로그래머가 어떻게 혼란스러워하는지 이해합니다. 내가 직접했다, 만약 내가 myString.equals ( "foo") 경우 의미 myString == "foo"경우 쓰기를 의미합니다. 그러나 모든 객체에 대해 == 연산자의 의미를 다시 디자인하지 않으면 해결 방법을 알 수 없습니다.

이에 대한 유효한 질문이다 Strings, 그리고뿐만 아니라 문자열뿐만 아니라, 예를 들어 일부 "값"을 나타내는 다른 불변의 객체에 대한 Double, BigInteger그리고 심지어 InetAddress.

==연산자를 문자열 및 기타 값 클래스와 함께 사용할 수 있도록하기 위해 세 가지 대안이 있습니다.

• 컴파일러에게 이러한 모든 가치 클래스와 내용을 비교하는 방법에 대해 알리십시오. java.lang패키지 의 소수 클래스 인 경우 고려할 것이지만 InetAddress와 같은 경우는 다루지 않습니다.

• 클래스가 ==비교 동작을 정의하도록 연산자 오버로드를 허용하십시오 .

• 퍼블릭 생성자를 제거하고 풀에서 인스턴스를 반환하는 정적 메소드를 사용하여 항상 동일한 값에 대해 동일한 인스턴스를 리턴하십시오. 메모리 누수를 피하려면 풀에 SoftReferences와 같은 것이 필요합니다. Java 1.0에는 없었습니다. 이제 호환성을 유지하기 위해 String()생성자를 더 이상 제거 할 수 없습니다.

오늘날에도 여전히 할 수있는 유일한 일은 연산자 오버로드를 도입하는 것입니다. 개인적으로 Java가 그 길을 가고 싶지는 않습니다.

나에게는 코드 가독성이 가장 중요하며 Java 프로그래머는 연산자가 언어 사양에 정의 된 고정 된 의미를 갖는 반면 메소드는 일부 코드로 정의되며 그 의미는 메소드의 Javadoc에서 찾아야한다는 것을 알고 있습니다. 문자열 비교에서 ==연산자를 사용할 수 없다는 의미가더라도 그 차이를 유지하고 싶습니다 .

나에게 성가신 Java 비교의 한 가지 측면이있다 : 자동 복싱과 -unboxing의 효과. 프리미티브와 랩퍼 유형 사이의 구별을 숨 깁니다. 그러나와 비교하면 ==매우 다릅니다.

    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?