Por que a comparação do valor da string do operador == não chegou ao Java?

Todo programador Java competente sabe que você precisa usar String.equals () para comparar uma sequência, em vez de == porque == verifica a igualdade de referência.

Quando estou lidando com seqüências de caracteres, na maioria das vezes estou verificando a igualdade de valor em vez de referenciar a igualdade. Parece-me que seria mais intuitivo se o idioma permitisse a comparação dos valores de string usando apenas ==.

Como comparação, o operador de C # == verifica a igualdade de valor da string s. E se você realmente precisou verificar a igualdade de referência, pode usar String.ReferenceEquals.

Outro ponto importante é que as Strings são imutáveis, portanto, não há danos a serem causados ​​ao permitir esse recurso.

Existe alguma razão específica para isso não ser implementado em Java?

Eu acho que é apenas consistência, ou "princípio de menor espanto". String é um objeto, portanto, seria surpreendente se ele fosse tratado de maneira diferente de outros objetos.

Na época em que o Java foi lançado (~ 1995), apenas ter algo parecido Stringera um luxo total para a maioria dos programadores que estavam acostumados a representar strings como matrizes com terminação nula. StringO comportamento de agora é o que era naquela época, e isso é bom; alterar sutilmente o comportamento posteriormente pode ter efeitos surpreendentes e indesejados nos programas de trabalho.

Como uma observação lateral, você pode usar String.intern()para obter uma representação canônica (interna) da sequência, após a qual as comparações podem ser feitas ==. A internação leva algum tempo, mas depois disso, as comparações serão muito rápidas.

Além disso: ao contrário de algumas respostas sugeridas, não se trata de oferecer suporte à sobrecarga do operador . O +operador (concatenação) funciona em Strings, mesmo que o Java não suporte a sobrecarga do operador; é simplesmente tratado como um caso especial no compilador, resolvendo para StringBuilder.append(). Da mesma forma, ==poderia ter sido tratado como um caso especial.

Então, por que surpreender com um caso especial, +mas não com ==? Porque +simplesmente não é compilado quando aplicado a Stringobjetos que não são objetos, o que é rapidamente aparente. O comportamento diferente de ==seria muito menos aparente e, portanto, muito mais surpreendente quando atingir você.

James Gosling , o criador do Java, explicou isso em julho de 2000 :

Eu deixei de fora a sobrecarga do operador como uma opção bastante pessoal, porque eu tinha visto muitas pessoas abusarem dela em C ++. Nos últimos cinco a seis anos, passei muito tempo pesquisando pessoas sobre a sobrecarga de operadores e é realmente fascinante, porque você divide a comunidade em três partes: provavelmente cerca de 20 a 30% da população considera a sobrecarga de operadores como a desova do diabo; alguém fez algo com sobrecarga de operador que realmente os marcou, porque eles usaram like + para inserção de lista e isso torna a vida muito, muito confusa. Muito desse problema decorre do fato de haver apenas meia dúzia de operadores que você pode sobrecarregar de maneira sensata e, no entanto, existem milhares ou milhões de operadores que as pessoas gostariam de definir - então você precisa escolher,

Consistência no idioma. Ter um operador que age de maneira diferente pode ser surpreendente para o programador. Java não permite que os usuários sobrecarregem os operadores - portanto, igualdade de referência é o único significado razoável ==entre objetos.

Dentro do Java:

• Entre tipos numéricos, ==compara igualdade numérica
• Entre tipos booleanos, ==compara igualdade booleana
• Entre objetos, ==compara a identidade de referência
  • Use .equals(Object o)para comparar valores

É isso aí. Regra simples e simples para identificar o que você deseja. Tudo isso é coberto na seção 15.21 do JLS . Compreende três subseções fáceis de entender, implementar e raciocinar.

Depois de permitir a sobrecarga== , o comportamento exato não é algo que você pode procurar no JLS, colocar um dedo em um item específico e dizer "é assim que funciona", o código pode se tornar difícil de raciocinar. O comportamento exato de ==pode ser surpreendente para um usuário. Toda vez que você o vê, precisa voltar e verificar o que realmente significa.

Como o Java não permite sobrecarregar os operadores, é necessário ter um teste de igualdade de valor do qual você possa substituir a definição básica. Assim, foi determinado por essas opções de design. ==em Java testa numérico para tipos numéricos, igualdade booleana para tipos booleanos e igualdade de referência para todo o resto (que pode substituir .equals(Object o)para fazer o que quiserem para igualdade de valor).

Não se trata de "existe um caso de uso para uma conseqüência específica dessa decisão de design", mas "é uma decisão de design para facilitar essas outras coisas, é uma consequência disso".

String interning , é um exemplo disso. De acordo com o JLS 3.10.5 , todos os literais de cadeia de caracteres são internados. Outras strings são internadas se alguém as invocar .intern(). Isso "foo" == "foo"é uma consequência das decisões de design tomadas para minimizar o espaço ocupado pela memória ocupado pelos literais String. Além disso, a internação de strings é algo que está no nível da JVM que tem um pouco de exposição ao usuário, mas na grande maioria dos casos, não deve ser algo que preocupa o programador (e os casos de uso para programadores não eram algo que estava no topo da lista para os designers ao considerar esse recurso).

As pessoas apontam isso +e +=estão sobrecarregadas com o String. No entanto, isso não é aqui nem ali. Continua sendo o caso que, se ==tiver um significado de igualdade de valor para String (e apenas String), seria necessário um método diferente (que só existe em String) para a igualdade de referência. Além disso, isso desnecessariamente complicaria os métodos que levam o Object e esperam ==se comportar de uma maneira e .equals()se comportar de outra, exigindo que os usuários criem casos especiais de todos esses métodos para String.

O contrato consistente para ==on Objects é que ele é apenas igualdade de referência e .equals(Object o)existe para todos os objetos que devem testar a igualdade de valor. Complicar isso complica muitas coisas.

Java não suporta sobrecarga de operador, o que significa que ==se aplica apenas a tipos ou referências primitivas. Qualquer outra coisa requer a invocação de um método. Por que os designers fizeram isso é uma pergunta que apenas eles podem responder. Se eu tivesse que adivinhar, provavelmente é porque a sobrecarga do operador traz complexidade que eles não estavam interessados ​​em adicionar.

Eu não sou especialista em C #, mas os designers dessa linguagem parecem configurá-la de tal maneira que todo primitivo é um structe todo structé um objeto. Como o C # permite a sobrecarga do operador, esse arranjo facilita muito a qualquer classe, e não apenas String, a trabalhar da maneira "esperada" com qualquer operador. C ++ permite a mesma coisa.

Isso foi diferenciado em outros idiomas.

No Object Pascal (Delphi / Free Pascal) e C #, o operador de igualdade é definido para comparar valores, não referências, ao operar em strings.

Particularmente em Pascal, string é um tipo primitivo (uma das coisas que eu realmente amo em Pascal, obter NullreferenceException apenas por causa de uma string não inicializada é simplesmente irritante) e ter semântica de copiar na gravação, tornando (na maioria das vezes) operações de string muito barato (em outras palavras, só é perceptível quando você começa a concatenar cadeias de vários megabytes).

Portanto, é uma decisão de design de linguagem para Java. Quando eles projetaram a linguagem, seguiram o caminho C ++ (como Std :: String), de modo que as strings são objetos, o que é um truque para compensar C sem um tipo de string real, em vez de torná-las primitivas (como são).

Portanto, por um motivo, posso apenas especular que eles facilitaram o processo e não codificaram o operador, fazendo uma exceção no compilador para seqüências de caracteres.

Em Java, não há sobrecarga de operador, e é por isso que os operadores de comparação são sobrecarregados apenas para os tipos primitivos.

A classe 'String' não é uma primitiva, portanto, não possui uma sobrecarga para '==' e usa o padrão de comparar o endereço do objeto na memória do computador.

Não tenho certeza, mas acho que no Java 7 ou 8 o oracle fez uma exceção no compilador para reconhecer str1 == str2comostr1.equals(str2)

O Java parece ter sido projetado para manter uma regra fundamental de que o ==operador deve ser legal a qualquer momento em que um operando possa ser convertido no tipo do outro e deve comparar o resultado dessa conversão com o operando não convertido.

Esta regra dificilmente é exclusiva do Java, mas tem alguns efeitos de longo alcance (e lamentável a IMHO) no design de outros aspectos da linguagem relacionados ao tipo. Teria sido mais claro especificar os comportamentos ==em relação a combinações particulares de tipos de operandos e proibir combinações dos tipos X e Y onde x1==y1e x2==y1não implicariam x1==x2, mas as línguas raramente fazem isso [sob essa filosofia, double1 == long1teriam que indicar se double1não é uma representação exata de long1, ou se recusa a compilar;int1==Integer1deve ser proibido, mas deve haver um meio conveniente e eficiente de não arremessar se um objeto é um número inteiro em caixa com valor específico (a comparação com algo que não é um número inteiro em caixa deve simplesmente retornar false)].

Com relação à aplicação do ==operador às seqüências de caracteres, se o Java proibisse comparações diretas entre operandos do tipo Stringe Object, poderia ter evitado surpresas no comportamento de ==, mas não há comportamento que possa ser implementado para essas comparações que não seriam surpreendentes. Ter duas referências de string mantidas no tipo Objectse comporta de maneira diferente das referências mantidas no tipo Stringteria sido muito menos surpreendente do que ter um desses comportamentos diferentes do de uma comparação legal de tipo misto. Se String1==Object1for legal, isso implicaria que o único caminho para os comportamentos String1==String2e Object1==Object2para corresponder String1==Object1seria que eles se correspondessem.

Em geral, há boas razões para querer testar se duas referências de objeto apontam para o mesmo objeto. Já tive muitas vezes que escrevi

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

Eu posso ou não ter uma função igual nesses casos. Se sim, a função equals pode comparar todo o conteúdo de ambos os objetos. Frequentemente, apenas compara algum identificador. "A e B são referências ao mesmo objeto" e "A e B são dois objetos diferentes com o mesmo conteúdo" são, obviamente, duas idéias muito diferentes.

Provavelmente é verdade que, para objetos imutáveis, como Strings, isso é menos problemático. Com objetos imutáveis, tendemos a pensar no objeto e no valor como sendo a mesma coisa. Bem, quando digo "nós", quero dizer "eu", pelo menos.

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

Claro que isso retorna falso, mas posso ver alguém pensando que deveria ser verdade.

Mas quando você diz que == compara alças de referência e não o conteúdo de Objetos em geral, criar um caso especial para Strings seria potencialmente confuso. Como alguém aqui disse, e se você quisesse comparar as alças de dois objetos String? Haveria alguma função especial para fazê-lo apenas para Strings?

E sobre ...

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

Isso é falso porque são dois objetos diferentes ou verdadeiro porque são Strings cujo conteúdo é igual?

Então, sim, eu entendo como os programadores ficam confusos com isso. Eu já fiz isso, quero dizer write if myString == "foo" quando eu quis dizer if myString.equals ("foo"). Mas, além de redesenhar o significado do operador == para todos os objetos, não vejo como resolvê-lo.

Esta é uma pergunta válida para Strings, e não apenas para cordas, mas também para outros objetos imutáveis que representam cerca de "valor", por exemplo Double, BigIntegere mesmo InetAddress.

Para tornar o ==operador utilizável com Strings e outras classes de valor, vejo três alternativas:

• Faça com que o compilador conheça todas essas classes de valor e a maneira de comparar seu conteúdo. Se fossem apenas algumas classes do java.langpacote, eu consideraria isso, mas isso não cobre casos como o InetAddress.

• Permitir sobrecarga do operador para que uma classe defina seu ==comportamento de comparação.

• Remova os construtores públicos e tenha métodos estáticos retornando instâncias de um pool, sempre retornando a mesma instância pelo mesmo valor. Para evitar vazamentos de memória, você precisa de algo como SoftReferences no pool, que não existia no Java 1.0. E agora, para manter a compatibilidade, os String()construtores não podem mais ser removidos.

A única coisa que ainda poderia ser feita hoje seria introduzir a sobrecarga do operador e, pessoalmente, não gostaria que o Java seguisse esse caminho.

Para mim, a legibilidade do código é mais importante, e um programador Java sabe que os operadores têm um significado fixo, definido na especificação da linguagem, enquanto os métodos são definidos por algum código, e seu significado deve ser pesquisado no Javadoc do método. Eu gostaria de permanecer com essa distinção, mesmo que isso signifique que as comparações de String não poderão usar o ==operador.

Há apenas um aspecto das comparações de Java que é irritante para mim: o efeito do boxe automático e da caixa unificada. Oculta a distinção entre o tipo primitivo e o tipo de invólucro. Mas quando você os compara ==, eles são MUITO diferentes.

    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?