Was soll das ?

[Was soll das ?]

public static void main(String args []) {
   String a = "";
   String b = new String("");

  System.out.println(a.equals(b));
}

???

 

[SlaterB]

was ist das Problem?
"" ist gleich "", egal in welchen String es enthalten ist,
falls du ein false haben möchtest, benutze ==

 

[Was soll das ?]

Genau das meinte ich ! Warum liefert == false und equals true ???

 

[Gast]

equals vergleicht den inhalt und == die referenzen

oder nicht?

 

[Was soll das ?]

ich hab keine Ahnung, ich glaube ich breche meinen Kurs wieder ab.. ;(

 

[Gast]

wozu denn gleich abbrechen...
Was ist das für ein Kurs?

 

[Guest]

na mein java kurs im 1.semester :-/
aber ok, ich glaube das schnall ich nun doch.

public static void main (String args []) {

  String a = "";
  String b = a;

  System.out.println(a==b);
}

[/code}
aha! das ist noch eine referenz. also ein objekt a und ein objekt b mit einer referenz auf a ??

 

[Gast]

String ist kein DatenTyp !
=> es sind Referenzen auf Objekte der Klasse String

 

[SlaterB]

b und a zeigen in diesem Fall auf das gleiche Objekt, deshalb ==,
b zeigt nicht auf a oder unterscheidet sich sonst irgendwie von a, das sind keine Objekte, schon gar nicht unterschiedliche,
das sind zwei String-Referenzen, die unabhängig voneinander auf ein String-Objekt ("") zeigen

im allgemeinen kann man sich recht sicher sein, dass bei Zuweisungen von explizit angegeben Strings im Quellcode immer die gleichen Objekte benutzt werden,
sich drauf verlassen aber nicht..,

problematisch wirds auf jeden Fall wenn Strings aus einer Datei eingelesen oder im Programm zusammengesetzt werden,
hier ist immer von neuen String-Objeken auszugehen,
auch wenn die Inhalte zufällig immer gleich sein sollten

bei String b = a; ist die Gleichheit in dem Moment garantiert

 

[AlArenal]

"Was soll das?" frage ich mich bei solchen Überschriften auch.

 

[Was soll das ?]

Aber warum sind das keine Objekte ? Ich dachte dies

String a = "";

ist nur eine verkürzte Schreibweise für

String a = new String("");

und der Compiler macht intern immer ein new String(""). So sagte es jedenfalls der Prof. ?

 

[AlArenal]

Ist ja auch korrekt so. Da Strings aber die Eigenart haben immutable zu sein, also nicht verändert werden zu können, kann die VM intern Strings gleichen Inhalts mit nur einer Instanz abbilden und dadurch den Ressourcenverbrauch optimieren. Demnach können gleich Strings, die man im Sourcecode hart codiert hat, auf dasselbe Objekt zeigen, müssen aber nicht.

So lange man sich nicht in die Lage manövriert Strings mit == vergleichen zu müssen, ist das aber alles relativ egal, weils hinter den Kulissen passiert und die Programmlogik nicht tangiert.

 

[Acha]

a und b sind schon Objekte, die von der Klasse String erzeugt werden. Aber Deine Frage galt doch dem Vergleich mit "==" und "equals". Und da ist zu sagen, dass "==" die Adressen vergleicht, wo im Speicher Deine Objekte abgelegt sind und ob vielleicht ein Objekt nur eine Referenz auf ein anderes Objekt ist (wenn Du z.B. a= b; ausführen würdest). Dagegen vergleicht "equals" als echte Stringoperation wirklich den Inhalt des Strings.

In anderen Programmiersprachen gibt es übrigens auch Vergleichsoperationen und zusätzliche Stringbefehle für den Stringvergleich, also egal ob Du jetzt Java oder eine andere Programmiersprache lernst, solltest Du an dieser Stelle immer aufpassen, was genau Du miteinander vergleichen willst!

MFG

Acha

 

[Wildcard]

Eigentlich sollte doch der Vergleich mit '==' deutlich schneller sein als ein String#equals.
Wenn man Strings also immer nur mit String#intern erzeugt kann man an mancher Stelle vieleicht sogar noch was rausholen.
Andererseits ist's ziemlich hässlich :autsch:

 

[AlArenal]

Optimierungen dieser Art überlasse ich der VM. Mittlerweile ist für viele Zwecke auch der Gebrauch des StringBuilders obsolet, so lange man es nicht mit einem Rutsch von zig tausend Operationen zu tun hat, da Compiler und VM da ebenfalls Optimierungen vornehmen.

Das ist der große Vorteil von VMs gegenüber statischen Kompilaten. Neuere VMs können Bytecode eben gezielt sowohl in Hinblick auf die CPU, als auch in Hinblick auf zur Laufzeit gemachte Beobachtungen hin optimieren. Das macht natürlich Voraussagen á la "machst du das so, ist ist das immer x% langsamer, als wenn du es so machst" nur schwer möglich.

Im Regelfall sollte die Aufgabe des Programierers aber in erster Linie in der Umsetzung und Lösung von Fachproblemen liegen und nicht in subtilen Optimierungen. Performance-Probleme enstehen ja nicht dort, wo ich mal zweihundert relati kurze Strings verbinde und/oder vergleiche.