OCA Study Guide: 2. Frage aus Kapitel 3

[andy938]

Hallo,


ich hab ein paar Fragen zu der folgenden Aufgabe aus dem OCA Oracle Certified Associate Java SE 8 Programmer I Study Guide.






Ist das richtig, wenn ich schreibe:

Die Bedingung in Zeile 5 („Hello“.equals(s)) ist wahr, weil „Hello“ und die Variable s die gleichen Zeichen haben. Die Methode equals vergleicht also die Zeichen von den String-Objekten „Hello“ und s.


Die Bedingung in Zeile 6 (t==s) ist falsch, weil t und s verschiedene Speicherorte (verschiedene Referenzen) im Heap haben.

Die Bedingung in Zeile 7 (t.equals(s)) ist wahr, weil t und s wieder die selben Zeichen haben.

Die Bedingung in Zeile 8 („Hello“ == s) ist wahr, weil „Hello“ und s den selben Speicherort im Heap haben.

Die Bedingung in Zeile 9 („Hello“ == t ) ist falsch, weil „Hello“ und t verschiedene Speicherorte haben.



In der Lösung steht „Line 7 also compares references but is true since both references point to the object from the string pool.“. Kann es sein, dass die Buchautoren hier einen Fehler gemacht haben, weil ich denke, dass line 8 und nicht line 7 gemeint ist.



Dann steht da noch „Finally, line 8 compares one object from the string poll with one that was explicitly constructed and returns false.“. Hier denke ich, dass line 9 und nicht line 8 gemeint ist.



Über Rückmeldung würde ich mich sehr freuen.

 

[httpdigest]

Jeden deiner Punkte sehe ich exakt wie du.

EDIT: Und viel Erfolg bei der Prüfung (wenn du sie noch vor dir hast)!

 

[DrPils]

Das Study Guide ist übrigens voll mit Fehlern.
Hier sind die meisten aufgelistet, ich meine aber damals auch welche entdeckt zu haben die nicht drinnen sind.
OCA STudy Guid Errate.
Das Buch ist im großen und ganzen dennoch gut

 

[Staarfightaar]

der string pool ist soweit ich mich erinnern kann eine hashmap mit nicht veränderbaren werten, deswegen wenn du string + string rechnest erstelts einen neuen string
der string pool ist im ( heap ? stack? weis ich nicht mehr ) und die string objekte sind genau auf dem anderen gespeichert
das .equals bei string vergleicht den inhalt und nicht referenzen deswegen ist es wurscht wos gespeichert ist

 

[DrPils]

deswegen wenn du string + string rechnest erstelts einen neuen string

Nicht ganz, wenn beides literale sind wird vom Stringpool genommen.

String literal = "abc" + "def";
System.out.println(literal == "abcdef");//true

String abc = "abc";
String variable = abc + "def";
System.out.println(variable == "abcdef");//false

 

[httpdigest]

Fun fact:

final String abc = "abc";
final String variable = abc + "def";
System.out.println(variable == "abcdef");//true!!!

Also: Wenn beides "Konstanten" sind, konkateniert javac das von alleine schon zusammen und der konkatenierte String steht dann an der Stelle im Bytecode.

 

[Staarfightaar]

mein prof hatte damals gesagt

wir haben versucht tief in die JVM rein zu gehen ... es war nicht schön

ob dieses wissen so nützlich ist ? puh... irgendwann nimmt man sowieso den stringbuilder her oder ähnliches

 

[httpdigest]

Für die Behandlung von konstanten String-Literalen braucht man gar nicht in die JVM reingehen. Das ist definiert im JLS:
- https://docs.oracle.com/javase/specs/jls/se7/html/jls-3.html#jls-3.10.5

Moreover, a string literal always refers to the same instance of class String. This is because string literals - or, more generally, strings that are the values of constant expressions (§15.28) - are "interned" so as to share unique instances, using the method String.intern.

- https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.28

A compile-time constant expression is an expression denoting a value of primitive type or a String that does not complete abruptly and is composed using only the following:
- The additive operators +
- Simple names (§6.5.6.1) that refer to constant variables (§4.12.4).

- https://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.12.4

A variable of primitive type or type String, that is final and initialized with a compile-time constant expression (§15.28), is called a constant variable.

 

[LimDul]

ob dieses wissen so nützlich ist ? puh... irgendwann nimmt man sowieso den stringbuilder her oder ähnliches

Meine Meinung: In der Detailtiefe - Definitiv nicht. Sprich, der Detailgrad der da abgefragt wird, das wird man nie wieder brauchen.

Aber das Wissen, dass es da Besonderheiten gibt, warum manchmal bei Strings == geht und manchmal nicht - das ist Wissen, was extrem wichtig ist. Zum einen um solche Fehler zu vermeiden, zum anderen um z.B. in Code Reviews sowas zu erkennen.

 

[KonradN]

ob dieses wissen so nützlich ist ? puh... irgendwann nimmt man sowieso den stringbuilder her oder ähnliches

Also ich denke, dass dieses Wissen sehr wichtig ist. Es geht hier eben nicht um die Internas der VM sondern um klare Festlegungen der Sprache. @httpdigest hat das ja sehr schön ausgeführt.

Und das ist ja ein Thema, dass sich deutlich weiter zieht. String.intern ist ja schon in der JLS erwähnt worden, also geht es in der Dokumentation des Java Frameworks gleich weiter.

Und es geht hier ja explizit um Verhalten von Java Code! Das sind also keine "internas", die eh nicht interessieren. Es geht um ein Verhalten von Code, den ich oder jemand anderes geschrieben hat und das ist etwas, das man kennen und erklären können sollte. Und dabei ist es egal, ob etwas im Heap, auf dem Stack oder sonst wo abgelegt ist. Das ist ja auch nicht spezifiziert und daher tatsächlich uninteressant.