Perché il confronto del valore della stringa dell'operatore == non è arrivato a Java?

Ogni programmatore Java competente sa che è necessario utilizzare String.equals () per confrontare una stringa, anziché == perché == verifica l'uguaglianza di riferimento.

Quando ho a che fare con le stringhe, la maggior parte delle volte cerco l'uguaglianza di valore piuttosto che l'uguaglianza di riferimento. Mi sembra che sarebbe più intuitivo se la lingua permettesse di confrontare i valori di stringa semplicemente usando ==.

Come confronto, l' operatore == di C # verifica la parità di valore per le stringhe . E se hai davvero bisogno di verificare l'uguaglianza di riferimento, puoi usare String.ReferenceEquals.

Un altro punto importante è che le stringhe sono immutabili, quindi non è possibile fare alcun danno consentendo questa funzione.

C'è qualche motivo particolare per cui questo non è implementato in Java?

Immagino sia solo coerenza o "principio del minimo stupore". String è un oggetto, quindi sarebbe sorprendente se fosse trattato in modo diverso rispetto ad altri oggetti.

All'epoca in cui uscì Java (~ 1995), avere semplicemente qualcosa di simile Stringera un lusso totale per la maggior parte dei programmatori che erano abituati a rappresentare le stringhe come array a terminazione nulla. StringIl comportamento è ora quello che era allora, ed è buono; cambiare in modo sottile il comportamento in seguito potrebbe avere effetti sorprendenti e indesiderati nei programmi di lavoro.

Come nota a margine, è possibile utilizzare String.intern()per ottenere una rappresentazione canonica (internata) della stringa, dopo la quale è possibile effettuare i confronti ==. Lo stage richiede un po 'di tempo, ma dopo, i confronti saranno molto veloci.

Aggiunta: a differenza di alcune risposte suggerite, non si tratta di supportare il sovraccarico dell'operatore . L' +operatore (concatenazione) funziona su Strings anche se Java non supporta il sovraccarico dell'operatore; è semplicemente gestito come un caso speciale nel compilatore, risolvendo StringBuilder.append(). Allo stesso modo, ==avrebbe potuto essere trattato come un caso speciale.

Allora perché stupire con il caso speciale +ma non con ==? Perché, +semplicemente non si compila quando applicato a non Stringoggetti, quindi è subito evidente. Il diverso comportamento di ==sarebbe molto meno evidente e quindi molto più sorprendente quando ti colpisce.

James Gosling , il creatore di Java, lo spiegò così nel luglio 2000 :

Ho lasciato il sovraccarico dell'operatore come una scelta abbastanza personale perché avevo visto troppe persone abusarne in C ++. Ho passato molto tempo negli ultimi 5-6 anni a sondare le persone sul sovraccarico dell'operatore ed è davvero affascinante, perché fai dividere la comunità in tre parti: probabilmente circa il 20-30% della popolazione pensa al sovraccarico dell'operatore come al spawn del diavolo; qualcuno ha fatto qualcosa con il sovraccarico dell'operatore che li ha appena spuntati, perché hanno usato come + per l'inserimento della lista e rende la vita davvero, molto confusa. Gran parte di questo problema deriva dal fatto che ci sono solo circa una mezza dozzina di operatori che puoi sovraccaricare sensibilmente, eppure ci sono migliaia o milioni di operatori che le persone vorrebbero definire - quindi devi scegliere,

Coerenza nella lingua. Avere un operatore che agisce diversamente può essere sorprendente per il programmatore. Java non consente agli utenti di sovraccaricare gli operatori, pertanto l'uguaglianza di riferimento è l'unico significato ragionevole ==tra gli oggetti.

All'interno di Java:

• Tra tipi numerici, ==confronta l'uguaglianza numerica
• Tra tipi booleani, ==confronta l'uguaglianza booleana
• Tra oggetti, ==confronta l'identità di riferimento
  • Utilizzare .equals(Object o)per confrontare i valori

Questo è tutto. Regola semplice e semplice per identificare ciò che vuoi. Tutto ciò è coperto nella sezione 15.21 del JLS . Comprende tre sottosezioni che sono facili da capire, implementare e ragionare.

Una volta che si consente il sovraccarico di== , il comportamento esatto non è qualcosa che si può guardare al JLS e mettere il dito su un elemento specifico e dire "è così che funziona", il codice può diventare difficile da ragionare. L'esatto comportamento di ==può essere sorprendente per un utente. Ogni volta che lo vedi, devi tornare indietro e controllare per vedere cosa significa effettivamente.

Poiché Java non consente il sovraccarico degli operatori, è necessario un modo per avere un test di uguaglianza di valore di cui è possibile ignorare la definizione di base. Pertanto, è stato richiesto da queste scelte progettuali. ==in Java test numerici per tipi numerici, uguaglianza booleana per tipi booleani e uguaglianza di riferimento per tutto il resto (che può sovrascrivere .equals(Object o)per fare ciò che vogliono per l'uguaglianza di valore).

Non si tratta di "esiste un caso d'uso per una particolare conseguenza di questa decisione progettuale", ma piuttosto "questa è una decisione progettuale per facilitare queste altre cose, ne è una conseguenza".

Lo string interning , ne è un esempio. Secondo JLS 3.10.5 , tutti i valori letterali di stringa sono internati. Altre stringhe vengono internate se si invoca .intern()su di esse. Questo "foo" == "foo"è vero è una conseguenza delle decisioni di progettazione prese per minimizzare il footprint di memoria assunto dai letterali String. Oltre a ciò, lo string interning è qualcosa a livello di JVM che ha un po 'di esposizione per l'utente, ma nella stragrande maggioranza dei casi, non dovrebbe essere qualcosa che riguarda il programmatore (e i casi d'uso per i programmatori non lo erano qualcosa che era in cima alla lista per i progettisti quando si considera questa funzione).

La gente lo farà notare +e +=sono sovraccarichi di String. Tuttavia, questo non è né qui né lì. Resta il caso che se ==ha un significato di uguaglianza di valore per String (e solo String), si avrebbe bisogno di un metodo diverso (che esiste solo in String) per l'uguaglianza di riferimento. Inoltre, ciò complicherebbe inutilmente i metodi che prendono Object e si aspettano ==di comportarsi in un modo e .equals()di comportarsi in un altro, richiedendo agli utenti casi speciali tutti quei metodi per String.

Il contratto coerente per gli ==oggetti è che si tratta solo di uguaglianza di riferimento e che .equals(Object o)esiste per tutti gli oggetti che dovrebbero verificare l'uguaglianza di valore. Complicare ciò complica troppe cose.

Java non supporta il sovraccarico dell'operatore, il che significa ==che si applica solo a tipi o riferimenti primitivi. Qualsiasi altra cosa richiede l'invocazione di un metodo. Perché i designer hanno fatto questa è una domanda a cui solo loro possono rispondere. Se dovessi indovinarlo, è probabilmente perché il sovraccarico dell'operatore porta complessità che non erano interessati ad aggiungere.

Non sono un esperto di C #, ma i progettisti di quel linguaggio sembrano averlo impostato in modo tale che ogni primitiva è un structe ogni structoggetto è un oggetto. Poiché C # consente il sovraccarico dell'operatore, tale disposizione rende molto semplice per qualsiasi classe, non solo String, far funzionare se stesso nel modo "previsto" con qualsiasi operatore. C ++ consente la stessa cosa.

Questo è stato reso diverso in altre lingue.

In Object Pascal (Delphi / Free Pascal) e C #, l'operatore di uguaglianza è definito per confrontare valori, non riferimenti, quando si opera su stringhe.

Soprattutto in Pascal, la stringa è un tipo primitivo (una delle cose che amo davvero di Pascal, ottenere NullreferenceException solo a causa di una stringa non inizializzata è semplicemente irritante) e avere una semantica copy-on-write che rende (per lo più) operazioni di stringa molto economico (in altre parole, evidente solo quando si inizia a concatenare stringhe multi-megabyte).

Quindi, è una decisione di progettazione del linguaggio per Java. Quando hanno progettato il linguaggio hanno seguito il modo C ++ (come Std :: String), quindi le stringhe sono oggetti, che è un hack di IMHO per compensare la mancanza di un tipo di stringa reale in C, invece di rendere le stringhe una primitiva (che sono).

Quindi, per un motivo, posso solo ipotizzare che abbiano reso tutto ciò facile da parte loro e non codificare l'operatore fa un'eccezione sul compilatore alle stringhe.

In Java, non c'è alcun operatore che sovraccarica di alcun tipo, ed è per questo che gli operatori di confronto sono sovraccaricati solo per i tipi primitivi.

La classe 'String' non è una primitiva, quindi non ha un sovraccarico per '==' e utilizza il valore predefinito per confrontare l'indirizzo dell'oggetto nella memoria del computer.

Non sono sicuro, ma penso che in Java 7 o 8 Oracle abbia fatto un'eccezione nel compilatore per riconoscerlo str1 == str2comestr1.equals(str2)

Java sembra essere stato progettato per rispettare una regola fondamentale secondo cui l' ==operatore dovrebbe essere legale ogni volta che un operando può essere convertito nel tipo di altro e dovrebbe confrontare il risultato di tale conversione con l'operando non convertito.

Questa regola non è univoca per Java, ma ha alcuni effetti di vasta portata (e sfortunati per IMHO) sulla progettazione di altri aspetti del linguaggio relativi al tipo. Sarebbe stato più pulito specificare i comportamenti ==riguardo a particolari combinazioni di tipi di operandi, e vietare combinazioni di tipi X e Y dove x1==y1e x2==y1non avrebbe implicato x1==x2, ma le lingue raramente lo fanno [secondo quella filosofia, double1 == long1o dovrebbero indicare se double1non è una rappresentazione esatta di long1, oppure rifiuta di compilare;int1==Integer1dovrebbe essere vietato, ma dovrebbe esserci un modo conveniente ed efficiente di non lancio per verificare se un oggetto è un intero boxed con un valore particolare (il confronto con qualcosa che non è un intero box dovrebbe semplicemente restituire false)].

Per quanto riguarda l'applicazione ==dell'operatore alle stringhe, se Java avesse vietato i confronti diretti tra operandi di tipo Stringe Object, avrebbe potuto piuttosto evitare le sorprese nel comportamento di ==, ma non c'è alcun comportamento che potrebbe implementare per tali confronti che non sarebbe sorprendente. Avere due riferimenti a stringa mantenuti nel tipo si Objectcomporta diversamente dai riferimenti mantenuti nel tipo Stringsarebbe stato molto meno sorprendente che avere uno di questi comportamenti differisca da quello di un confronto legale di tipo misto. Se String1==Object1è legale, ciò implicherebbe che l'unico modo per i comportamenti String1==String2e la Object1==Object2corrispondenza String1==Object1sarebbe che si abbinassero l'un l'altro.

In generale, ci sono ottime ragioni per voler poter verificare se due riferimenti a oggetti puntano allo stesso oggetto. Ho avuto molte volte che ho scritto

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

In tali casi, potrei o meno avere una funzione uguale. Se lo faccio, la funzione uguale può confrontare l'intero contenuto di entrambi gli oggetti. Spesso confronta solo un identificatore. "A e B sono riferimenti allo stesso oggetto" e "A e B sono due oggetti diversi con lo stesso contenuto" sono, ovviamente, due idee molto diverse.

È probabilmente vero che per gli oggetti immutabili, come le stringhe, questo è meno un problema. Con oggetti immutabili, tendiamo a pensare all'oggetto e al valore come la stessa cosa. Bene, quando dico "noi", intendo almeno "io".

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

Naturalmente questo restituisce falso, ma posso vedere qualcuno pensare che dovrebbe essere vero.

Ma una volta che dici che == confronta gli handle di riferimento e non i contenuti per gli oggetti in generale, creare un caso speciale per le stringhe sarebbe potenzialmente fonte di confusione. Come ha detto qualcun altro qui, e se volessi confrontare le maniglie di due oggetti String? Ci sarebbe qualche funzione speciale per farlo solo per le stringhe?

E che mi dici di ...

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

È falso perché sono due oggetti diversi o vero perché sono stringhe il cui contenuto è uguale?

Quindi sì, capisco come i programmatori si confondano con questo. L'ho fatto da solo, intendo scrivere se myString == "pippo" quando volevo dire se mioString.equals ("pippo"). Ma a parte riprogettare il significato dell'operatore == per tutti gli oggetti, non vedo come affrontarlo.

Questa è una domanda valida per Strings, e non solo per le stringhe, ma anche per altri oggetti immutabili che rappresentano alcuni "valore", per esempio Double, BigIntegere persino InetAddress.

Per rendere l' ==operatore utilizzabile con stringhe e altre classi di valori, vedo tre alternative:

• Chiedi al compilatore di conoscere tutte queste classi di valore e il modo di confrontare i loro contenuti. Se fosse solo una manciata di classi dal java.langpacchetto, lo prenderei in considerazione, ma questo non copre casi come InetAddress.

• Consenti il ​​sovraccarico dell'operatore in modo che una classe definisca il suo ==comportamento di confronto.

• Rimuovere i costruttori pubblici e disporre di metodi statici che restituiscono istanze da un pool, restituendo sempre la stessa istanza per lo stesso valore. Per evitare perdite di memoria, è necessario qualcosa come SoftReferences nel pool, che non esisteva in Java 1.0. E ora, per mantenere la compatibilità, i String()costruttori non possono più essere rimossi.

L'unica cosa che si potrebbe ancora fare oggi sarebbe introdurre il sovraccarico dell'operatore, e personalmente non mi piacerebbe che Java seguisse quella strada.

Per me, la leggibilità del codice è molto importante e un programmatore Java sa che gli operatori hanno un significato fisso, definito nella specifica del linguaggio, mentre i metodi sono definiti da un codice e il loro significato deve essere cercato nel Javadoc del metodo. Vorrei rimanere con questa distinzione anche se ciò significa che i confronti String non saranno in grado di utilizzare l' ==operatore.

C'è solo un aspetto dei paragoni di Java che mi dà fastidio: l'effetto dell'auto-boxing e -unboxing. Nasconde la distinzione tra il tipo primitivo e il tipo di wrapper. Ma quando li confronti ==, sono MOLTO diversi.

    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?