String i equals a ==

WItam!
Pisalem programik z zalozeniem ze String == String porowna napisy (tak jak jest to w c++) tera czytam ze operator== porownuje wskazniki a nie stringi... hmm ale umnie z == dziala dobrze:D porownujac 2 stringi z 2 roznych obiektow wyrzuca true... (co innego gdyby to byly takie same obiekty;] )
Ksiazka ktora czytam opisuje JDK 1.3 moze w kolejnej wersji operator== zostal tak przeladowany ze porownuje napisy ?? Bo sie zastanawiam, czy poprawiac kod....

Popraw, na

x.equals(y)

Tylko ze kodu troche jest 3000 linijek.. i szukac tego hmm.. bo przeciez dziala dobrze, sprawdzalem wielokrotnie(co innego gdyby nie dzialalo ;] )
Moze ktos wie czy w wersji wiekszej jak 1.3 zostal zmieniony operator porownania ?

Nie zostało zmienione.
Z grubsza rzecz biorąc operator == działa zgodnie z twoimi oczekiwaniami gdy Stringi są wyznaczane na etapie kompilacji:

String s1="Test";
String s2="Te"+"st";
String s3=new String("Test"); 
s1==s2?"Tak":"Nie":  //Tak
s1==s3?"Tak":"Nie":  //Nie

== na pewno porównuje w przypadku Stringów referencje a nie ich zawartość. Kod na pewno nie działa dobrze - działa przypadkowo. Jeśli porównywane Stringi są zadeklarowane jako stałe to jest szansa (ze względu na to, że kompilator używa stałych zdefiniowanych jako pewnej puli referencji), że porównania dają wynik true.

Generalnie porównywanie zawartości leksykalnej obiektu String prze operator '==' nie ma najmniejszego sensu.

Pozdrawiam.

@gzrewal, zgadzam się całkowicie. Moim zdaniem program zależny od wyniku porównania (s1==s2) jest błędny.
Przykład przypadkowości:

public class Test
{
    public static void main(String[] args)
    {
        String s1="Przed";
        String s2="Przed";
        System.out.println(s1==s2?"Tak":"Nie"); //Tak
        s1="Po";
        StringBuffer s=new StringBuffer("Po"); 
        s2=s2.toString();
        System.out.println(s1==s2?"Tak":"Nie"); //Nie
    }
}

wszystkie stringi sa wyznaczane na etapie kompilacji, dlatego tez to niby dziala, ale dla pewnosci pozmieniam kod...
DZIEKI WSZYSTKIM ;-)

Jezeli jest sie swiadomym, jak dokladnie dziala == mozna go z powodzeniem uzywac i nie spotka sie problemow.

Tak jak wyzej zosatlo napisane operator == porownuje referencje.
Warto jednak w tym momencie napisac o czyms takim jak 'wewnetrzna pula stringow'.

Otow, kazde stworzenie obiektu typu String za pomoca "jakis napis" sprawia, ze maszyna wirtualna sprawdza, czy w puli stringow jest juz taki sam string, jak tak, to zwraca referencje wskazujaca na juz istniejacy obiekt, natomiast jesli nie ma, to umieszcza w puli tego stringa.

jawny konstruktor new String() a takze wszelkie operacje zwracajace string, typu: .substring(), trim() itd nie korzystaja z tej puli a wynik umieszczaja poza nia, przez co porownywanie z tymi obiektami da false.

Klasa String posiada metoda intern(), ktora w skrocie: sprawdza czy string taki jak nasz jest w puli, jak tak to zwaraca do niego referencje, jak nie to umiescza go tam i zwraca do niego referencje.

Zatem, jakby sie uprzec, to zawsze mozna porownywac stringi za pomoca operatora ==, np:

String a = "xx";
String b = new String("xx");

b = b.intern();

a == b // zwroci true

Jednak, jak napisalem, jest to "na sile". Sa sytuacje, gdzie jest to bardzo przydatne, jak i sytuacje gdzie nie nalezy tego robic.

@Luno - uważam, że to co piszesz to po prostu mylenie koncepcji programowania Obiektowego z programowaniem... nawet nie wiem jakim. To jest Java, nie C nie C++, po to są comparatory i metoda equals żeby ich używać - porównanie leksykalne powinno korzystać tylko i wyłącznie z tej metody.

Prawda, że jeśli ktoś jest świadomy tego, jak działa JVM to może próbować bawić się w porównania typu == gdzie wyraźnie chodzi o komparator ale nie sądzą, żeby OP (bez urazy) był świadom działania JVM.

Pozdrawiam,

Obiekt String jest zaprojektowany w sposób zbliżony do wzorca Flyweight. Zgodzę się z gzrewalem, że narzędzi należy używać zgodnie z ich przeznaczeniem. Szczególnie w tak drażliwej kwesti jak operacje na tekście duża swoboda w używaniu == i equals może prowadzić do poważnych błędów. Trzeba o tym pamiętać i stosować zasadę ograniczonego zaufania.