Comparando argumentos com == [resolvido]

Olá gente,
na minha saga pela certificação, trago aqui mais um paradigma rsrsr

observem o código

executando com

java Classe antonio


public static void main(String[] args) {

		
		String[] args2 = new String[1];
		
		args2[0] = "rafael";
		
		System.out.println("Comparando um array com equals -->     "+args2[0].equals("rafael"));
		
		System.out.println("Comparando um array com == -->         "+(args2[0] == "rafael"));		
				
		System.out.println("Comparando um argumento com equals --> "+args[0].equals("antonio"));
		
		System.out.println("Comparando um argumento com ==  -->    "+(args[0] == "antonio"));
				
		
		
	}

executando esse código a saída é a seguinte:

Comparando um array com equals --> true
Comparando um array com == --> true
Comparando um argumento com equals --> true
Comparando um argumento com == --> false

Viram?

Quando eu comparo um elemento de um array de strings com == ele retorna true mas se esse item é do array de strings dos argumentos ele retorna false, porem se comparado com equals ele retorna true.

alguém sabe o porque ?

Quando voce compara com “==”, você está comparando os bits do objeto que contem na variavel.
Como as variaveis estão apontando para objetos diferentes, ocorre esse “false”.
Mas se você comparar com equals, o resultado será true, como voce fez anteriormente.

Exemplo:

String nome = “Antonio”;
String nome2 = nome;
System.out.println(nome2==nome);

//o resultado será true, pq as variaveis apontam para o mesmo objeto.

Ué …

disso eu sei
mas com as Strings não acontece isso em java5
eu posso comparar as Strings com == é como se fosse um AutoBoxing
mas porque essa distinção? quando eu comparo uma string de um array que eu criei … ele dah true … mas quando eu comparo uma string do array de argumentos ele mostra false …

o q eu quero dizer é q o java tah se comportando de forma diferente nas duas ocasiões …

dá uma olhada na chamada que eu usei (java Classe antonio) e no código que eu passei que vc vai entender a pergunta XD

brigaduuuu XD

Não tenho certeza, mas parece que é por causa do pool de Strings, quando você cria a String dentro da classe ele consegue encontrar e por isso a saída é true, e quando vc recebe pelo console ele não encontra.

É isso que o gilmaslima escreveu, por causa do pool de Strings, ocorre aquele resultado:
exemplo:

String nome = “Antonio”;
String nome2 = “Antonio”;
System.out.println(nome2==nome);

//true, pq ele verifica no pool de strings e utiliza o que está lá

String nome = “Antonio”;
String nome2 = new String(“Antonio”);
System.out.println(nome2==nome);

//false, pq ele utiliza “new”, criando um objeto.

Po … entendi agora …

se ele vem do argumento ele não está no pool , portanto não tera o mesmo endereço de memoria … e portanto será diferente … saquei XD

mas só mais uma dúvida

como é que eu sei se a string vai entrar no pool de strings ou não?

Por motivos de desempenho e economia de memória, a JVM evita de criar duas Strings iguais, usando para isso o pool de Strings.String a = "xxx"; String b = "xxx"; String c = "xxx";Ao invés de criar três Strings idênticas, ela cria uma só. Desta forma, a, b e c apontam para o mesmo objeto.

tá … mas quando eu sei se a string vai ou não para o pool ??

se ela é criada com o new não vai?
se ela é criada sem o new vai?
se ela vem como argumento de linha de comando não vai

se ela retorna de um método vai?

como é q eu sei … de acordo com a forma q ela foi declarada … se ela vai para o pool de strings? para estra disponivel caso outra igual seja criada

valewwww

[quote=javando]Po … entendi agora …

se ele vem do argumento ele não está no pool , portanto não tera o mesmo endereço de memoria … e portanto será diferente … saquei XD

mas só mais uma dúvida

como é que eu sei se a string vai entrar no pool de strings ou não?[/quote]

As Strings que aparecem hardcoded completas no código-fonte estarão no pool.
Algumas Strings montadas com diversos operadores + também irão para o pool se o compilador conseguir otimizar isso reduzindo-a a uma única String hardcoded.
Essas Strings hardcoded são criadas quando a classe é carregada e ficam lá até a JVM encerrar, ou em alguns casos, até o coletor de lixo recolher o objeto da classe (algo bem incomum que requer configurações especiais da JVM).
Você pode adicionar uma String ao pool chamando o método intern().[code]
public class Kxx {
public void foo() {
String x = “aaa”;
String y = “bbb” + “ccc”;
String z = “aaa” + nn() + “ddd”;
}

public String nn() {
    return "aaa";
}

}[/code]Neste exemplo, quando a classe Kxx for carregada “aaa”, “ddd” e “bbbccc” serão colocadas no pool. Estas String NÃO são criadas dentro dos métodos foo() e nn(), e sim quando a classe é carregada pela JVM, e ficam lá no pool. Quando os métodos foo() e nn() são chamados, as variáveis simplesmente apontam para os objetos já existentes.
“aaa” e “ddd” estão hardcoded, logo irão para o pool. O compilador é inteligente o suficiente para reduzir “bbb” + “ccc” para “bbbccc” e então colocá-lo no pool também. Apenas a String z não estará no pool porque o compilador não será capaz de determiná-la durante a compilação.

(bem, acho que é isso, se falei besteira, alguém me corrija aí)

[quote=javando]tá … mas quando eu sei se a string vai ou não para o pool ??

se ela é criada com o new não vai?
se ela é criada sem o new vai?
se ela vem como argumento de linha de comando não vai

se ela retorna de um método vai?

como é q eu sei … de acordo com a forma q ela foi declarada … se ela vai para o pool de strings? para estra disponivel caso outra igual seja criada

valewwww

[/quote]


String s = new String("S"); // <-- Cria um objeto no pool de Strings e um objeto no heap e faz a variavel [b]s[/b] referenciar a String 

String a = "A" // <- Cria uma string no pool de Strings 

PS. tirei essa do livro da Kathy

Era essa mesmo a minha dúvida …

Brigadão gente XD

VALEW