Olha que pegadinha nesse código!

Em java, Strings são imutáveis. Procure nos artigos do GUJ ou no blog da Caelum (não lembro onde eu vi) que tem uma explicação muito legal.

Olha não sei está certo, mas se você juntar a String “A” + “B” vai ficar AB, tipo se fizer “8” + “9” fica 89, vai uma string atrás da outra.

portanto “A” + “B” == “AB”
e
“A” + “B” == c (c == “AB”)
mesma coisa que acima…

O grande causo é o pool de Strings.
RafaelViana, você está parcialmente enganado. Quer um exemplo? Rode:

String a = "A"; String b = "B"; String c =a+b; String d = new String("AB"); System.out.println(c==d);
E veja se vai dar true.

Tem um site que achei que acho que a explicação está boa:
http://www.xyzws.com/javafaq/what-is-string-literal-pool/3

Até!

Que vacilo, as referências apontam para as mesmas String, afinal todas elas estão no pools, básico !!!

Só pra deixar mais claro vai esse exemplo simples

//Novo Objeto String - false
		String carro = new String("audi");
		System.out.println(carro=="audi");

		//Referencia está apontando para string do pool - true
		carro = "audi";
		System.out.println(carro=="audi");

O código que você postou é equivalente ao seguinte código, para o compilador:

class Orange {
  public static void main(String args[]) {
    String a = "A";
    String b = "B";
    String c = "AB";
    System.out.print((("AB")=="AB") + ",");
    System.out.print(("AB")==c);
  }
}

É que quando você tem concatenação de constantes strings, o compilador entende que você quer na verdade é uma outra constante string, que seja o resultado da concatenação.
E como sabemos que as constantes strings estão no pool, então o resultado é “true”, “true”.
Mas isso é na verdade um detalhe de implementação; você precisa procurar na JLS (Java Language Specification) se isso é requerido pela definição da linguagem ou não.

Na verdade não entendi pq você achou que seria false,false

Seria false, false se não houvesse esse recurso de constantes strings estarem no pool. Dessa forma, o operador “==” iria sempre retornar false porque , como sabemos, normalmente objetos com o mesmo conteúdo mas comparados com “==” retornam false, porque não são o mesmo objeto.
== compara referências de objetos, não conteúdo de objetos.

So retornaria True True se estivesem sendo comparadas utilizando o equals, que no caso compara o valor da String.

Você não entendeu a pegadinha. Ele retorna true, true mesmo sem usar o equals!

Na verdade eu também achei, e o motivo é o seguinte:
À primeira vista, a impressão é que ao fazer “A”+“B” seria gerado um novo objeto String (tem aquela história de fazer a operação usando StringBuffer…). Este objeto teria o valor “AB”, mas não seria a mesma instância da literal “AB” (que está no pool).

Porém, o grande Thingol mais uma vez salva o dia:

pintofree:

So retornaria True True se estivesem sendo comparadas utilizando o equals, que no caso compara o valor da String.

hmmmm … entendi! se eu tivesse algo do tipo

class Inteiro{
   private int value;

   public Inteiro( int v ){ value = v };
}

class Test
{
    public void test()
    {
      Inteiro i1 = new Inteiro( 5 );
      Inteiro i2 = new Inteiro( 5 );

      System.out.println(  i1 == i2 );
    }
}

O resultado seria false, pois i1 e i2 referenciam objetos diferentes, mas com o mesmo valor. Porém , no caso das Strings, se eu tiver

class Test
{
    public void test()
    {
      String s1 = "abc";
      String s2 = "abc";

      System.out.println(  s1 == s2 );
    }
}

O resultado é true, pois com o recurso de pool de Strings, s1 e s2 referenciam o mesmo objeto, é isso?

Muito bem explicado pelo thingol

rmendes08:

hmmmm … entendi! se eu tivesse algo do tipo

O resultado é true, pois com o recurso de pool de Strings, s1 e s2 referenciam o mesmo objeto, é isso?

é isso sim.

ops!

hmm… Até a última vez que chequei (que foi há muitos anos atrás) a especificação do Java dizia que você não podia “confiar” no pool de Strings, que o comportamento é indeterminado. Ou seja, uma implementação do Java pode realmente reaproveitar o objeto sempre que possível e outra pode reaproveitar só quando der vontade, e ambas poderiam ser chamadas de “Java compatible”.

Isso mudou? :hunf:

Bani:

hmm… Até a última vez que chequei (que foi há muitos anos atrás) a especificação do Java dizia que você não podia “confiar” no pool de Strings, que o comportamento é indeterminado. Ou seja, uma implementação do Java pode realmente reaproveitar o objeto sempre que possível e outra pode reaproveitar só quando der vontade, e ambas poderiam ser chamadas de “Java compatible”.

Isso mudou? :hunf:

Olá Bani, vc corrigiu meus programas em Mac122, blz?

Acho que mudou sim dá uma olhada

http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.10.5

Interessante.
Semestre que vem devo estar corrigindo EPs de MAC115, em Java, então bom saber! hehe

LuizClaudio:

…

A string literal is always of type String (§4.3.3). A string literal always refers to the same instance (§4.3.1) of class String.

gomesrod:

LuizClaudio:

…

A string literal is always of type String (§4.3.3). A string literal always refers to the same instance (§4.3.1) of class String.

Mas e quanto à concatenação de literais (+)? Será que existe um comportamento garantido?

Eu entendi que sim. Vc leu a link abaixo

http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.10.5

Nesse artigo está bem explicado:
http://www.javaranch.com/journal/200409/ScjpTipLine-StringsLiterally.html