Чому порівняння значень рядка == оператора не зробило його Java?

Кожен компетентний програміст Java знає, що вам потрібно використовувати String.equals () для порівняння рядка, а не ==, тому що == перевіряє рівність еталону.

Коли я маю справу з рядками, більшу частину часу я перевіряю на рівність значення, а не на рівність еталон. Мені здається, було б інтуїтивніше, якби мова дозволила порівнювати рядкові значення, використовуючи ==.

Для порівняння, оператор C # 's == перевіряє рівність значення для рядка s. І якщо вам дійсно потрібно було перевірити рівність еталону, ви можете використовувати String.ReferenceEquals.

Ще одним важливим моментом є те, що рядки незмінні, тому шкоди не можна зробити, якщо дозволити цю функцію.

Чи є якась конкретна причина, чому це не реалізовано на Java?

Я здогадуюсь, що це просто послідовність, або "принцип найменшого здивування". Рядок - це об'єкт, тому було б дивно, якби трактували його інакше, ніж інші об'єкти.

У той час, коли з'явилася Java (~ 1995), просто мати щось подібне Stringбуло цілковитою розкішшю для більшості програмістів, які звикли представляти рядки як нульові завершені масиви. Stringповедінка тепер є те, що було тоді, і це добре; тонка зміна поведінки згодом може мати дивовижні, небажані наслідки в робочих програмах.

Як бічну примітку, ви можете використовувати String.intern()для отримання канонічного (інтернованого) представлення рядка, після чого можна проводити порівняння ==. Стажування займає деякий час, але після цього порівняння будуть дійсно швидкими.

Доповнення: на відміну від деяких відповідей, це не про підтримку перевантаження оператора . +Оператор (конкатенація) працює на Stringз , навіть якщо Java не підтримує оператор перевантаження; це просто обробляється як окремий випадок у компіляторі, який вирішує StringBuilder.append(). Так само ==можна було б розглядати як окрему справу.

Тоді чому дивуватися особливим випадком, +але не цим ==? Тому що, +просто не компілюється при застосуванні до не- Stringоб’єктів, так що це швидко видно. Різна поведінка в ==буде набагато менш очевидно і , таким чином , набагато більш дивно , коли він вдаряє вас.

Джеймс Гослінг , творець Java, пояснив це так ще в липні 2000 року :

Я залишив перевантаження оператора як досить особистий вибір, тому що я бачив, як занадто багато людей зловживають цим на C ++. Я провів багато часу за останні п’ять-шість років, опитуючи людей про перевантаження операторів, і це дійсно захоплююче, тому що ви розбиваєте громаду на три частини: Напевно, приблизно 20-30 відсотків населення вважають перевантаження оператора як нерест чорта; хтось щось зробив із перевантаженням оператора, що просто дійсно позначив їх, тому що вони використовували як + для вставки списку, і це робить життя справді дуже заплутаною. Багато з цієї проблеми випливає з того, що є лише близько півдесятка операторів, яких ти можеш відчутно перевантажувати, і все ж є тисячі чи мільйони операторів, які люди хотіли б визначити - тому ти повинен вибрати,

Послідовність всередині мови. Наявність оператора, який діє по-різному, може здивувати програміста. Java не дозволяє користувачам перевантажувати операторів - тому рівність посилань є єдиним розумним значенням ==між об'єктами.

В межах Java:

• Між числовими типами ==порівнює числову рівність
• Між булевими типами ==порівнює булева рівність
• Між об'єктами ==порівнює посилання на ідентичність
  • Використовуйте .equals(Object o)для порівняння значень

Це воно. Просте правило і просте визначення того, що ви хочете. Це все висвітлено у розділі 15.21 JLS . Він складається з трьох підрозділів, які легко зрозуміти, впровадити та обґрунтувати.

Як тільки ви дозволите перевантаження== , точна поведінка не є чимось, на що ви можете звернути увагу на JLS і покласти пальцем на певний предмет і сказати "ось як це працює", про це може стати важко обґрунтувати. Точна поведінка користувача ==може здивувати користувача. Кожного разу, коли ви його бачите, вам доведеться повертатися назад і перевіряти, що це насправді означає.

Оскільки Java не дозволяє перевантажувати операторів, потрібен спосіб провести тест рівності значень, на який можна переосмислити базове визначення. Таким чином, це було доручено цим вибором дизайну. ==в Java тестує числові типи для числових типів, булева рівність для булевих типів і опорна рівність для всього іншого (що може замінити .equals(Object o)виконання всього, що вони хочуть, за рівності значення).

Це не питання "чи є випадок використання певного наслідку цього дизайнерського рішення", а, скоріше, "це проектне рішення для полегшення цих інших речей, це є наслідком цього".

Струнне інтернування - один із таких прикладів. Згідно з JLS 3.10.5 , всі рядкові літерали інтерновані. Інші рядки інтерновані, якщо один викликає .intern()їх. Це "foo" == "foo"правда, це наслідок дизайнерських рішень, прийнятих для мінімізації сліду пам’яті, прийнятого літералами String. Крім того, струнне інтернування - це те, що знаходиться на рівні JVM, що має незначну експозицію користувача, але в переважній більшості випадків не повинно бути те, що стосується програміста (а випадки використання для програмістів не були те, що було високо в списку для дизайнерів при розгляді цієї функції).

Люди вкажуть на це +і +=перевантажені для String. Однак цього немає ні тут, ні там. Залишається випадок, що якщо ==має значення рівності значення для String (і лише String), для еталонної рівності знадобиться інший метод (який існує лише у String). Крім того, це зайво ускладнить методи, які сприймають Object і очікують, що ==вони поводяться в один бік і .equals()поводяться по-іншому, вимагаючи від користувачів спеціального випадку всіх цих методів для String.

Послідовний договір ==на об’єкти полягає в тому, що це лише еталонна рівність і .equals(Object o)існує для всіх об'єктів, які повинні перевірити ціннісну рівність. Ускладнення цього ускладнює занадто багато речей.

Java не підтримує перевантаження оператора, а це ==стосується лише примітивних типів або посилань. Все інше вимагає виклику методу. Чому дизайнери це зробили, це питання, на яке вони можуть відповісти. Якби мені довелося здогадуватися, це, мабуть, тому, що перевантаження оператора приносить складність, вони не зацікавлені в додаванні.

Я не знаю C #, але, здається, дизайнери цієї мови встановили це таким чином, що кожен примітив є a, structа кожен struct- об'єктом. Оскільки C # дозволяє перевантажувати оператора, таке розташування дозволяє дуже легко будь-якому класу, а не тільки String, змусити себе працювати "очікуваним" способом з будь-яким оператором. C ++ дозволяє те саме.

На інших мовах це було різним.

У Object Pascal (Delphi / Free Pascal) та C # оператор рівності визначений для порівняння значень, а не посилань при роботі над рядками.

Особливо в Pascal, рядок є примітивним типом (одна з речей, яку мені дуже подобається в Pascal, отримання NullreferenceException саме через неініціалізовану рядок просто дратує) і має семантику копіювання на запис, що робить (більшість часу) рядкові операції дуже дешево (іншими словами, помітно лише після того, як ви почнете об'єднувати багатомігабайтні рядки).

Отже, це рішення мовного дизайну для Java. Коли вони розробляли мову, вони слідували способу C ++ (наприклад, Std :: String), тому рядки - це об'єкти, що IMHO хак компенсувати, що C не має реального типу рядка, а не робить рядки примітивними (якими вони є).

Тож з причини, чому я можу лише припускати, що вони зробили це легко на своїй стороні і не кодуючи оператора, роблять виняток для компілятора до рядків.

У Java немає оператора, який би перевантажував, і тому оператори порівняння перевантажуються лише для примітивних типів.

Клас 'String' не є примітивом, тому він не має перевантаження для '==' і використовує за замовчуванням порівняння адреси об'єкта в пам'яті комп'ютера.

Я не впевнений, але думаю, що в Java 7 або 8 oracle зробив виняток у компіляторі, щоб визнати str1 == str2якstr1.equals(str2)

Здається, Java була створена для того, щоб дотримуватися принципового правила, згідно з яким ==оператор повинен бути легальним у будь-який час, коли один операнд може бути перетворений на тип іншого, і повинен порівнювати результат такого перетворення з неперетвореним операндом.

Це правило навряд чи є унікальним для Java, але воно має певний далекосяжний (і IMHO прикро) вплив на дизайн інших аспектів мови, що стосуються типу. Було б чіткіше уточнити поведінку ==щодо конкретних комбінацій типів операндів, а також заборонити комбінації типів X і Y там, де x1==y1і як x2==y1це не випливає x1==x2, але мови, які рідко роблять це [згідно з цією філософією, double1 == long1повинні були або вказувати, чи double1не є точним поданням long1, а то інакше відмовлятися від компіляції;int1==Integer1слід забороняти, але повинні бути зручні та ефективні засоби, що не підкидають, для перевірки того, чи є об'єкт цілим кодом з певним значенням (порівняння з тим, що не є цілим коробкою, просто повертається false)].

Що стосується застосування ==оператора до рядків, якби Java забороняла прямі порівняння між операндами типу Stringі Object, це могло б досить добре уникнути сюрпризів у поведінці ==, але немає такої поведінки, яку він міг би реалізувати для таких порівнянь, які б не дивували. Наявність двох посилань на рядки, що зберігаються в типі, Objectповодяться по-різному від посилань, що зберігаються у типі, Stringбуло б набагато менш дивовижним, ніж будь-яке з цих типів поведінки відрізняється від правового порівняльного змішаного типу. Якщо String1==Object1це законно, це означатиме, що єдиним способом поведінки String1==String2та Object1==Object2відповідності String1==Object1є те, щоб вони відповідали один одному.

Загалом, є дуже вагома причина, щоб хотіти тестувати, чи дві посилання на об'єкт вказують на один і той же об'єкт. Я багато разів писав, що писав

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

Я можу або не матиму функцію рівності в таких випадках. Якщо я це зробити, функція рівня може порівнювати весь вміст обох об'єктів. Часто він просто порівнює якийсь ідентифікатор. "A і B - це посилання на один і той же об'єкт", а "A і B - це два різних об'єкти з однаковим змістом", звичайно, дві дуже різні ідеї.

Напевно, правда, що для незмінних об'єктів, таких як Strings, це менше питання. З незмінними предметами ми схильні думати про предмет і значення як про одне і те ж. Що ж, коли я кажу "ми", я маю на увазі "я", принаймні.

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

Звичайно, це повертає помилкове значення, але я бачу, що хтось думає, що це має бути правдою.

Але як тільки ви скажете, що == порівнює контрольні ручки, а не вміст для Об'єктів взагалі, створення спеціального випадку для Strings було б потенційно заплутаним. Як тут говорив хтось інший, що робити, якщо ви хочете порівняти ручки двох об'єктів String? Чи буде якась особлива функція робити це лише для Strings?

А як же ...

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

Це помилково, тому що вони є двома різними об'єктами, чи правда, тому що вони є рядками, зміст яких рівний?

Так, так, я розумію, як програмісти плутають це. Я це зробив сам, я маю на увазі написати if myString == "foo", коли я мав на увазі, якщо myString.equals ("foo"). Але, якщо не змінити значення оператора == для всіх об'єктів, я не знаю, як це вирішити.

Це дійсно питання для Strings, а не тільки для рядків, але і для інших незмінних об'єктів , що представляють деякі «цінність», наприклад Double, BigIntegerі навіть InetAddress.

Для того, щоб зробити ==оператора придатним до використання Strings та інших класів цінностей, я бачу три варіанти:

• Повідомте компілятору про всі ці класи цінності та спосіб порівняння їх вмісту. Якби це була лише декілька занять з java.langпакету, я б вважав це, але це не охоплює випадки, такі як InetAddress.

• Дозволити оператору перевантажувати, щоб клас визначав його ==поведінку порівняння.

• Видаліть загальнодоступні конструктори та використовуйте статичні методи, що повертають екземпляри з пулу, завжди повертаючи той самий екземпляр для того ж значення. Щоб уникнути витоку пам'яті, вам потрібно щось подібне до SoftReferences в пулі, якого не було в Java 1.0. А тепер, щоб зберегти сумісність, String()конструктори більше не можна видаляти.

Єдине, що можна було б зробити сьогодні, - це запровадити перевантаження оператора, і особисто мені не хотілося б, щоб Java йшла цим маршрутом.

Для мене найважливіша читабельність коду, і Java-програміст знає, що оператори мають фіксований сенс, визначений у мовній специфікації, тоді як методи визначаються деяким кодом, і їх значення слід шукати в Javadoc методу. Я хотів би залишитися з цією відмінністю, навіть якщо це означає, що порівняння String не зможе використовувати ==оператор.

Існує лише один аспект порівняння 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?