einfache Quizfrage programmieren

[dylar]

Ich möchte eine Quizfrage programmieren auf die geantwortet werden kann. Ist die Antwort richtig, soll "Richtig" ausgegeben werden, ist sie falsch soll "leider falsch" ausgegeben werden. Die Frage ist "Wer erfand die Glühbirne", Antwort soll "Edison" sein. Folgendes habe ich dazu programmiert:

import java.util.Scanner;

public class Quiz {
	public static void main (String args[]){
    Scanner input = new Scanner(System.in);
    
        System.out.println("Wer erfand die Glühbirne? ");
        String Antwort = input.nextLine ();
        
        if (Antwort == "Edison"){
        	System.out.println ("richtig");
        	
        }else{
        	System.out.println ("leider falsch");
        	
        }
	}
}

Es wird auch die Frage ausgegeben, ich kann meine Antwort eingeben, aber dann gibt das Programm immer nur "leider falsch" aus. Ich vermute ich mache das mit

 if (Antwort == "Edison")

falsch, oder?

 

[supertux]

Hi, ich bin selbst Anfänger aber ich habe gelesen das == nicht möglich ist du musst dafür equal oder so nehmen dann müsste es gehen... (Habe jetzt leider keinen Link parat)

 

[Volvagia]

Das stimmt so nicht, == ist möglich und macht grundsätzlich das selbe wie equal. Der einzige Unterschied ist, dass equal überschrieben werden kann (keine Überladungen in Java), und bei Strings den Inhalt des String vergleicht.

Variablennamen sollte man übrigens wenn möglich immer klein schreiben.

 

[dylar]

ah ok. Also so funktioniert es jetzt:

import java.util.Scanner;

public class Quiz {
	public static void main (String args[]){
    Scanner input = new Scanner(System.in);
    
        System.out.println("Wer erfand die Glühbirne? ");
        String antwort = input.nextLine ();
        
        if (antwort.equals ("Edison")){
        	System.out.println ("richtig");
        	
        }else{
        	System.out.println ("leider falsch");
        	
        }

herzlichen Dank.

 

[kirax]

Das stimmt so nicht, == ist möglich und macht grundsätzlich das selbe wie equal. Der einzige Unterschied ist, dass equal überschrieben werden kann (keine Überladungen in Java), und bei Strings den Inhalt des String vergleicht.

Das ist FALSCH.

String str1 = "string1";
String str2 = "string1";
System.out.println(str1 == str2);  // possibly true, usually false
System.out.println(str1 == "string1");  // possibly true, usually false
System.out.println(str1.equals(str2));  // always true

String str3 = "string1";
String str4 = new String("string1");
System.out.println(str3 == str4);  // always false
System.out.println(str3.equals(str4));   // always true

Warum ist das so?
Bei [c]==[/c] wird geprüft, ob die Referenz gleich ist, während [c]equals[/c] überprüft, ob der Inhalt gleich ist. Und weil bei eigenen Klassen selbst definiert werden muss, wann der Inhalt gleich ist, muss equals jeder selbst implementieren (deswegen ist sie überschreibbar).

Was ist da jetzt der Unterschied?
Die Referenz ist genau dann gleich, wenn die beiden Objekte auf die gleiche Stelle im Speicher zeigen. Denn es kann durchaus mehrere Objekte mit den gleichen Parametern geben, aber eben an unterschiedlichen Stellen im Speicher. In diesen Fällen würde equals true ausgeben, == aber false.

Was ist das Besondere an Strings?
Strings sind die einzigen Objekte, die (neben ihren komplexen Vertretern) wie primitive Datentypen initialisiert werden können. Die JVM behält sich bei dieser Methode vor, gleichlautenden Strings u.U. die selbe Referenz (=selbe Adresse im Speicher) zu geben. Das macht sie aus Performancegründen.
Das macht sie aber nicht immer. Insbesondere meist dann nicht, wenn die Strings an völlig verschiedenen Stellen definiert wurden (was in deinem Beispiel zwar nicht so aussieht, aber so sein wird).
str4 im obigen Beispiel wird definitiv als neues Objekt deklariert. Da wird die JVM auf keinen existierenden String verweisen.

equals vergleicht bei Strings auf den Inhalt. Deswegen ist der Test [c]str3.equals(str4))[/c] auch immer wahr, weil der Inhalt gleich ist.

Im Übrigen lässt sich equals() sehr wohl überladen:

@Override
public boolean equals(Object t) {
  return true;
}
    
public boolean equals(Integer i) {
  return true;
}

 

[Volvagia]

Das er die String-Cache nicht verwendet hängt jetzt nicht mit dem Ort der Definition zusammen, sondern damit, dass der String mit new instanziert wurde.

[java=1940]new String(offset + beginIndex, endIndex - beginIndex, value);[/code]

Und doch, equal macht prinzipiell das selbe wie ==:

public class Object {
    public boolean equals(Object obj) {
	return (this == obj);
    }
}

Zudem habe ich nie behauptet, dass equal nicht überschrieben werden kann, ich hab genau das Gegenteil gesagt. ???:L

 

[kirax]

Ich bin jetzt zu faul in der Spec nachzulesen (wenn das überhaupt genau geregelt ist). Aber es gibt Fälle, in denen gleichlautende Strings die gleiche Referenz haben und andere, in denen das nicht so ist (siehe das Problem des TE).
Mit new erzwinge ich lediglich, dass ein neues Objekt angelegt wird (mit anderem Speicherort und damit anderer Referenz). Das sollte auch nur als Beispiel dienen, in denen das auf jeden Fall passiert.

Und nur Object.equals() macht dasselbe wie [c]==[/c]. Das hat aber nichts mit dem Problem des Vergleichs bei String zu tun, denn da ist equals() überschrieben.

Was stimmt, ist folgendes:
[c]o1 == o2 ==> o1.equals(o2)[/c]
Das ist in der Spezifikation von equals geregelt (und hat damit für alle Overrides von equals zu gelten). Aber
[c]o1.equals(o2) ==> o1 == o2[/c] gilt nicht. Sonst bräuchte man equals nicht, weil wozu dann überschreiben

Du hattest geschrieben "keine Überladungen in Java". Ich hatte das auf equals() bezogen. Aber offenbar meintest du damit die Operatorüberladung von [c]==[/c]. Dann sorry

 

[tsitra]

Hallo,

hier kann ich was zur Entscheidung beitragen.
Folgendes halte ich für eine gewagte bzw. eher falsche Behauptung

Und doch, equal macht prinzipiell das selbe wie ==

Es müsste eher heißen:
"equals macht manchmal genau das selbe wie =="

kirax hat das schon recht gut erklärt, warum das eben doch verschieden ist.

Es gibt Fälle in denen "x.equals(y)" das gleiche liefert wie "x == y" aber das sollte nicht darüber hinwegtäuschen, dass "equals()" und "==" eigentlich wesentlich verschieden sind!

Die "equals()" aus Object nutzt "==" und == prüft Bitgleichheit also liefert nur true wenn
der Zeiger identisch ist.
Das ist natürlich viel zu streng um Bedeutungsgleichheit
(Inhaltsgleichheit) zu überprüfen! Aus dem Grund MUSS jede class, deren Instanzen miteinander
auf Bedeutungsgleichheit getestet werden sollen, equals() überschreiben.
Dabei kann dann entschieden werden, welche die Kriterien für Bedeutungsgleichheit sein sollen.

Java nutzt ein sogenannten "StringConstantPool"(Ich denke Vovagia meint diesen mit "String-Cache") und deshalb ist bei
String str1 = "string1";
String str2 = "string1";

str1 == str2 ist immer true, aber das hatte kirax bereits erwähnt.

Jede neue String Variable strNeu bekommt die selbe Referenz wie ein String Literal (konkreter String-Wert) strX im "StringConstantPool"sofern der Wert von StrNeu genau gleich strX ist.
Wird ein ganz neuer String xyz verwendet, der noch nicht im "StringConstantPool" ist, so
wird der dort eingetragen und ab dann, zeigen alle etwaigen Clons davon genau auf xyz.

Viele Grüße
tsitra

 

[kirax]

String str1 = "string1";
String str2 = "string1";

str1 == str2 ist immer true, aber das hatte kirax bereits erwähnt.

Naja da wär ich nicht so sicher.
Siehe das Problem vom TE. Genau deswegen muss man Strings ja mit equals vergleichen.

 

[tsitra]

Hallo kirax,
vertust Du Dich jetzt nicht oder missverstehst mich?
Also nochmal:

WENN
String str1 = "string1";
String str2 = "string1";
DANN:
Der Vergleich str1 == str2 liefet immer true,

In dem Fall, dass zwei Strings str1 und str2 identische Werte haben und NICHT mit new
erzeugt wurden, sondern einfach nur mit String deklariert wurden,
sind diese, wegen dem String Constant Pool immer bezüglich == gleich, also
"referenzgleich".

Innerhalb "String Antwort = input.nextLine ();" wird wohl ein new String(...)
ausgeführt, wodurch danach der Gleichheitstest nur noch mit equals()
gemacht werden kann, wenn man inhaltsgleiche Strings als solche erkennen will.

Viele Grüße
tsitra

 

[kirax]

Doch, ich verstehe, was du sagen willst. Und ich versuche dir auch zu glauben.
Nur:

String Antwort = input.nextLine ();
if (Antwort == "Edison")

Wenn [c]Antwort[/c] den gleichen Inhalt wie "Edison" hält, dann dürfte "Edison" in der Abfrage (nach deiner Theorie) nicht als neues String-Objekt erzeugt werden (was nichts damit zu tun hat, ob für Antwort in der ersten Zeile ein neuer String erzeugt wird, oder nicht), sondern die JVM würde hierfür die Referenz des (einzigen?) String-Objekts mit dem Inhalt "Edison", worauf sich ja auch [c]Antwort[/c] beziehen würde, einsetzen. Damit wäre der Vergleich [c]true[/c].

Verstehst du, was ich meine?
Du darfst mir gern helfen, meinen Fehler zu finden, aber ich sehe ihn nicht.....

 

[tsitra]

Hallo kirax,
etwas verworren Dein Einwand, also schwer zu verstehen.

Ich nehme an, mit Abfrage meinst Du "input.nextLine ();"

Du schriebst:

"Wenn Antwort den gleichen Inhalt wie "Edison" hält, dann dürfte "Edison" in der Abfrage (nach deiner Theorie) nicht als neues String-Objekt erzeugt werden ..."

Es ist das Gegenteil von dem was ich in meinem ersten Beitrag geschrieben habe,
denn da beschrieb ich, dass es beides gibt, so wie Du es auch dargelegt hattest.
Wo habe ich das also behauptet?
Ich habe nirgendwo behauptet, dass ein andere Stringvariable str2, die jedoch
inhaltsgleich mit str1 ist, IMMER intern auf die str2 zeigt.

Ich habe die JVM und die API nicht programmiert, daher weiss ich nicht was da intern geschieht.Doch ich sehe genau, dass der Vergleich (Antwort == "Edison") false gibt und dafür muss es eine Ursache geben.
Ganz wichtig ist es also, dass die praktischen Fakten gesehen werden.

Ich stelle mir vor, dass der rechte Teil also "input.nextLine ();" eine Referenz
zurückliefert auf einen String namens "Edison", der jedoch eine andere Instanz
ist. Es gibt also in dem Fall zwei mal ein "Edison" im Speicher.

Du schriebst in einem früheren Beitrag:
"Mit new erzwinge ich lediglich, dass ein neues Objekt angelegt wird (mit anderem Speicherort und damit anderer Referenz). Das sollte auch nur als Beispiel dienen, in denen das auf jeden Fall passiert."
Das scheint mir nah an der Lösung des Problems dran. Hattest Du das vergessen?

Liegt es hier nicht nahe, dass genau das hier passiert und deshalb (Antwort == "Edison")
zu false evaluiert wird?

Viele Grüße
tsitra