Arquivo Discussoes de Programacao e Tecnologia Qual linha será impresso false, explicação.
import static java.lang.System.out;
public class Myclass {
static String s1 = "I am unique!";
public static void main(String[] args) {
String s2 = "I am unique!";
String s3 = new String(s1);
out.println(s1 == s2); //linha 1
out.println(s1.equals(s2)); //linha 2
out.println(s3 == s1); //linha 3
out.println(s3.equals(s1)); //linha 4
}
//Em qual linha é impresso false?
}
Acho que é as Linhas 1 e 3
Tmb acho que seja nas linhas 1 e 3 porque você esta comparando objetos com o “==” e para a comparação de objetos se utiliza o método equals().
Somente a linha 3.
A linha 1, apesar de usar o ==, vai retornar true pq irá se beneficiar do cache de strings que o Java tem.
Toda string criada com aspas é colocada num cache. Quando a mesma string é requisitada novamente, usando-se novamente as aspas, um novo objeto de string não é criado, e o do cache é retornado. Por isso, a comparação com == funciona, já que ambas apontam efetivamente para a mesma referência.
A criação com o new nunca utiliza o cache.
PS: Apesar de ser interessante conhecer esse fato, basear-se nele em seus programas é uma forma grosseira de POG. Então, siga a dica dos colegas e só compare string com equals.
A resposta correta é somente a linha 3, e valeu pela explicação.
achei que seria 1 e 3, não sabia que pegava do cache mesmo sem usar new, achei ela sempre consideraria 2 diferentes… boa explicação ViniGodoy
Somente a linha 3.A linha 1, apesar de usar o ==, vai retornar true pq irá se beneficiar do cache de strings que o Java tem.
Toda string criada com aspas é colocada num cache. Quando a mesma string é requisitada novamente, usando-se novamente as aspas, um novo objeto de string não é criado, e o do cache é retornado. Por isso, a comparação com == funciona, já que ambas apontam efetivamente para a mesma referência.
A criação com o new nunca utiliza o cache.
PS: Apesar de ser interessante conhecer esse fato, basear-se nele em seus programas é uma forma grosseira de POG. Então, siga a dica dos colegas e só compare string com equals.
E é por isso que existem “strings” e “symbols” no Ruby (já que temos nosso fórum de Ruby, e pegando carona naquela discussão). No caso do Ruby, as strings seriam sempre criadas com o equivalente a “new String” do java, e os symbols seriam strings que são sempre internadas no pool de strings. (O equivalente a pegar uma string retornada por String.intern).
No caso do Java não há esse tipo de técnica como sendo um “recurso da linguagem”. Em Java usar strings internadas e compará-las com “==” parece algo meio POG - principalmente porque não deve funcionar direito quando se usa aquela multidão de classloaders que você acaba enfrentando em application servers.
Só vi isso sendo usado no Thinlet (que aliás usa um monte de técnicas estranhas para economizar espaço de código. Uma delas é usar uma classe gigantesca; outra é comparar strings com “==”. )