Tava fazendo uns testes, com equals aqui:
[code]StringBuilder sb = new StringBuilder(“everton”);
StringBuilder sb1 = new StringBuilder(“everton”);
System.out.println(sb.equals(sb1));[/code]
Porque equals() com 2 objetos StringBuilders retornou false? È porque StringBuilder nao sobreescreve equals() de Object?
Exatamente. Se StringBuilder sobreescrevesse equals, teria de converter o buffer para uma String e então comparar, o que é uma operação lenta. Em vez disso, ele simplesmente nem sobreescreve o equals de Object.
Everton,
Só String e Wrappers implementam equals por padrão mas não StringBuilder, nos outros casos em que não se implementam equals são comparadas as referências , isto é quando as referências “apontam” pro mesmo objeto , equals é true (como bem citado pelo colega a implementação de equals herdada de Object) .
Dessa forma só retonaria true se :
StringBuilder sb = new StringBuilder("everton");
StringBuilder sb1 = sb;
Ou se os objetos fossem String .
[]'s
Luiz Renato
Opaaa Vlww!!
Talvez a não sobrescrita de equals() esteja relacionada mais a um entendimento conceitual sobre a classe que ao desempenho em si.
Afinal, por trás de String, StringBuilder e StringBuffer estão arrays de caracteres.
O tempo de comparação no pior caso é o mesmo para objetos dessas classes (LENGTH).
Entretanto, já pensei sobre a mutabilidade do objeto, sobre a individualidade de buffers distintos, mas nao cheguei a nenhuma conclusão.
Pensando por outro lado, quando usamos fortemente equals() (e também hashCode())? Ao preencher Collections. Faz sentido inserir buffers em coleções?
Imagine ter um Set de StringBuilders, zona pura! Dois buffers distintos de mesmo conteúdo devem ser considerados iguais?
Atenção, pois eles sequer implementam Comparable! Buffers são classes utilitárias!
Ao que me parece, aí está a parte conceitual.