Olha que pegadinha nesse código!

Programação Java
#1

Olá Pessoal

Eu poderia jurar que o código abaixo imprimiria: "false,false", mas imprime "true,true" .Alguém sabe explicar pq? 

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

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.

#3

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…

#4

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é!

#5

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

#6

Só pra deixar mais claro vai esse exemplo simples

[code] //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");[/code]
#7

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.

#8

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

#9

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.

#10

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

#11

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

#12

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: :smiley:

#13

[quote=pintofree]So retornaria True True se estivesem sendo comparadas utilizando o equals, que no caso compara o valor da String.[/quote] viajei na maionese aki pessoal, desculpa e a fome.

#14

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?

#15

Muito bem explicado pelo thingol

#16

[quote=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?[/quote]

é isso sim.

#17

ops!

#18

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:

#19

[quote=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: [/quote]

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

#20

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