Schon gewusst?

[stev.glasow]

Integer a = Integer.valueOf(88);
Integer b = Integer.valueOf(88);
System.out.println(a == b);
// Ausgabe: treu

valueOf(int) cachet die Instanzen der Werte -128 < x < 128 und liefert die jeweilige Instanz zurück. (Is bissel blöd erklärt.)

Kennt ihr noch mehr solche Schoten?

 

[stev.glasow]

Danke jdar:

String s0,s1 = s0 = "Bin neu hier.";

Hätte drauf schwören können, dass das nicht geht.

 

[bygones]

Integer a = Integer.valueOf(88);
Integer b = Integer.valueOf(88);
System.out.println(a == b);
// Ausgabe: treu

valueOf(int) cachet die Instanzen der Werte -128 < x < 128 und liefert die jeweilige Instanz zurück. (Is bissel blöd erklärt.)
Kennt ihr noch mehr solche Schoten?

willkommen in Java 5

Sun bereut mittlerweilen in den Wrapper Klassen einen public Konstruktor reingehauen zu haben - man sollte immer (!) die valueOf Methode nutzen.

Noch eindeutiger ist es bei der Klasse Boolean. Man sollte nicht zigtausend mal new Boolean(true) schreiben, sondern Boolean.valueOf("true") bzw. Boolean.TRUE

 

[stev.glasow]

Achso, das gibt's erst ab der 1.5er. Das mit Boolean gab's ja schon vorher. Frag mich nur warum Integer.valueOf(String) das nicht so händelt.

 

[meez]

:bahnhof:

Ich versteh nur ..ähh... Ich versteh eigentlich gar nichts...?

 

[stev.glasow]

:bahnhof:

Ich versteh nur ..ähh... Ich versteh eigentlich gar nichts...?

Hm, und nu? Oder hast du in dem Satz ne Frage versteckt? Wegen dem Fragezeichen.

 

[0xdeadbeef]

@meez:
Hier werden Referenzen verglichen, die ja nur dann gleich sind, wenn sie tatsächlich auf das selbe Objekt verweisen. Per "valueOf" erzeugt man also keine neuen Instanzen, wenn ein Objekt gleichen Inhalts bereits existiert.´

@Stevg:
"treu" -> "true" würde das Verständnis evtl. vereinfachen...

IMHO war das aber mit Stringliteralen auch schon immer so.

 

[stev.glasow]

IMHO war das aber mit Stringliteralen auch schon immer so.

Unverständlicher Weise nicht.
[edit] ne ich meinte Integer.valueOf(String) oder was meinst du jetzt?

 

[0xdeadbeef]

String a = "Lurch";
String b = "Lurch";
boolean lurchi = (a == b);

 

[stev.glasow]

Achso. Jetzt ist's klar.

 

[Wildcard]

Ich finde das auch sehr seltsam. Das verhalten von Integer.valueOf und String hört sich für mich auf den ersten Blick gleich an.

für jedes Zeichenketten-Literal im Programm wird (bei Bedarf) automatisch ein entsprechendes String-Objekt erzeugt. Dies geschieht für jede konstante Zeichenkette höchstens einmal, egal wie oft sie im Programmverlauf benutzt wird.

Weiß jemand woran das liegt?

 

[0xdeadbeef]

Ist halt ein schlauer Compiler, der die Ressourcen schont. Das ganze ist ja auch völlig ungefährlich, weil Strings und Wrapper-Objekte "immutable" sind.

 

[Beni]

Das liegt am Compiler, der da eifrig deinen Sourcecode optimiert :wink: (da ist glaub direkt in String ein Cach eingebaut?)

 

[stev.glasow]

Das ist nicht ganz das gleiche, das was in dem Zitat erwähnt wird läuft "intern" ab, denn new String("hallo") == "hallo" ergibt ja false, aber trotzdem wird nur eine Zeichenkette gespeichert. (Kein Plan wer das jetzt Regel, hatte eigentlich angenommen das dass die VM macht und nicht der Compilier.)
Und das mit Integer.valueOf(int) läuft nicht so, das wurde einfach mit Java so programmiert.
[edit]
oder so ähnlich :?

 

[0xdeadbeef]

Das mit den Stringliteralen macht zumindest aller Wahrscheinlichkeit der Compiler. Wäre jedenfalls die sinnvollste und performanteste Lösung.

 

[Wildcard]

Alles klar! bleibt aber noch eine Frage:
Warum haben SUN Klassen teilweise solche Rückgabewerte?

return new String()

Warum wird nicht auch hier String.valueOf() verwendet?
Mir drängt sich die Frage auf warum man für Integer, String, usw...überhaupt einen public Konstruktor zulässt und so unnöte Objekte vermeidet?
Gäbe es den nicht könnte man Strings auch problemlos mit '==' vergleichen und es würde im Anfängerbereich
ungefähr 1000 Threads zum Thema Stringvergleich weniger geben :wink:

 

[stev.glasow]

Die von Sun sind halt auch nur Menschen Und damit die Abwärtskompatibilität erhalten bleibt, läßt man die Public Konstruktoren drin. Bestimmt gibt es bei der Thematik auch noch einiges mehr zu beachten als dass was wir hier mit unseren Geistesblitzen erfasst haben. :wink:

 

[thE_29]

Da stellt sich die Frage, wann brauche ich das

Ich handhabe die Objekt Datentypen Klassen sowieso fast nie (also Integer, Long, Double) da ich immer mit den double, long, int arbeite weil ich das noch von C/C++ gewohnt war

Am Anfang habe ich sogar meine eigenen Int -> String funktionen geschrieben, bis ich draufgekommen bin, dass es sowas schon gibt

Aber die Konstruktoren habe ich nie genutzt ..

 

[stev.glasow]

Wenn du z.B. nen int in einer Collection verwenden willst, könnte die Wrapper Klasse ganz praktisch sein :bae:

 

[bygones]

Wenn du z.B. nen int in einer Collection verwenden willst, könnte die Wrapper Klasse ganz praktisch sein :bae:

man kann aber auch um den Wrapper Dingesn aus dem Weg zu gehen mit arrays arbeiten

 

[stev.glasow]

Nä, ich nicht.

 

[thE_29]

hrhr

Ich mach das so, ist halt noch von C so

Ihr seid ja alle verwöhnt von Java mit Arraylists usw. in C geht das net mal

int x[var];

Man muss vor dem Compileren schon eine fixe Anzahl reinschreiben, also

int x[20];

Tjojo, so ne ArrayList muss man sich in C++ halt selber schreiben, aber mit den Templates usw haut das schon hin, aber im normalen C, tjo, blöde Sache :bae:

 

[Bleiglanz]

Mir drängt sich die Frage auf warum man für Integer, String, usw...überhaupt einen public Konstruktor zulässt und so unnöte Objekte vermeidet?

Hä? Ohne Konstruktor?

Willst du die 2^32 möglichen Instanzen eines Integers irgendwo ablegen und bei bedarf zurückgeben? Das geht wohl nicht

Bleibt also ein private Konstruktor mit Factory-Methode, aber wie soll der aussehen?

Integer.newInstance(123434);

würde ja wohl nix bringen, da ist doch new Integer(123434) genauso gut??

Gäbe es den nicht könnte man Strings auch problemlos mit '==' vergleichen und es würde im Anfängerbereich
ungefähr 1000 Threads zum Thema Stringvergleich weniger geben

Ein Vergliech mit == hat bei Strings und den Wrapper-Klassen fast NIE einen Sinn, in Java 5 sogar noch weniger als früher (weitere Verwirrung durch boxing)

wie soll ein Prog funktionieren, dass alle Strings intern(); macht und dann bei jedem (dynamischen) neuen String den ganzen Stringpool durchsuchen muss -> das geht nicht!!

wenns dir leichter fällt: wie soll z.B. Double seine Instanzen verwalten, damit == äquivalent zu equals ist; mit endlichem Speicher ziemlich unmöglich...

 

[stev.glasow]

Ob man die nun mit == vergleichen kann oder nicht finde ich auch nicht wichtig. Aber wenn man das Integer.valueOf(int) schon von Anfang an so gehändelt hätte würde ein private Konstruktor doch schon Sinn machen.

 

[thE_29]

Man hätte bei den Strings ja eigentlich auch den == operator überschreiben können ;>

Warum isn das eigentlich nicht gemacht worden? Weil der + operator ist ja auch überschrieben...

Wären halt viele Fragen weniger, warum das nicht geht wenn ich if(string == "HALLO") mache

 

[stev.glasow]

Man hätte bei den Strings ja eigentlich auch den == operator überschreiben können ;>

Warum isn das eigentlich nicht gemacht worden? Weil der + operator ist ja auch überschrieben...

Wären halt viele Fragen weniger, warum das nicht geht wenn ich if(string == "HALLO") mache

Weil man mit == nicht den Inhalt vergleicht sondern ob es die gleiche Referenz ist.
Sonst würde ja 'new String("hä") == new String("hä")' true ergeben, und das wär irgendwie ... naja

 

[thE_29]

Naja, hast recht, dann würde Referenz vergleich wegfallen. Aber braucht man den so oft??

Manchmal isses für mich ärgerlich das man keine Operatoren überladen kann, das war in C++ super

Aber was solls, man kommt auch ohne aus

 

[stev.glasow]

Naja, hast recht, dann würde Referenz vergleich wegfallen. Aber braucht man den so oft??

Manchmal isses für mich ärgerlich das man keine Operatoren überladen kann, das war in C++ super

Aber was solls, man kommt auch ohne aus

Och Operatorenüberladen is Schnickschnack. Was ist verständlicher ohne groß in der Doku der entsprechenden Klasse zuschauen? a + b oder a.append(b)?

 

[meez]

Hier werden Referenzen verglichen, die ja nur dann gleich sind, wenn sie tatsächlich auf das selbe Objekt verweisen. Per "valueOf" erzeugt man also keine neuen Instanzen, wenn ein Objekt gleichen Inhalts bereits existiert.´
en...

axo, das habt ihr gemeint...

 

[thE_29]

Es kommt darauf an was a+b machen soll

Hast du zB 2 Klassen Mensch und du machst a + b kannst du halt sagen was dann rauskommen soll

soll sich nur das Gewicht zusammen zählen, oder soll das dann heißen sie sind verheiratet (sprich Namensänderung) usw

operatoren Überladen hat schon sinn (stimmt sie tragen zur Verwirrung bei, deswegen immer gut dokumentieren )

 

[Kirsche]

Das ist nicht ganz das gleiche, das was in dem Zitat erwähnt wird läuft "intern" ab, denn new String("hallo") == "hallo" ergibt ja false, aber trotzdem wird nur eine Zeichenkette gespeichert. (Kein Plan wer das jetzt Regel, hatte eigentlich angenommen das dass die VM macht und nicht der Compilier.)
Und das mit Integer.valueOf(int) läuft nicht so, das wurde einfach mit Java so programmiert.
[edit]
oder so ähnlich :?

new Strinf("hallo") wird zur Laufzeit erstellt "hello" kann er schon beim Compilieren umsetzen und behandelt er so komplett anders.
Deswegen der Unterschied!

Gruß
Kirsche

 

[stev.glasow]

new Strinf("hallo") wird zur Laufzeit erstellt "hello" kann er schon beim Compilieren umsetzen und behandelt er so komplett anders.

Aha also doch der Compiler, aber die Zeichenkette ist doch aber trotzdem nur einmal im Speicher vorhanden, oder?

Deswegen der Unterschied!

Welchen Unterschied meinst du? Ich hatte von dem Unterschied zwischen String und Integer.valueOf(int) gesprochen.


Oder habe ich das jetzt ganz falsch verstanden, worauf du hinnaus willst?

 

[Spacerat]

Schon vom StringBuffer gehört? (Nein, ich meine nicht die gleichnamige Java-Klasse!)

Beim 1. Instanzieren eines Strings (z.B. String s1="Hello") wird durch die JVM automatisch ein StringBuffer angelegt. die Variable s1 selber erhält nur einen (Offset-??) Zeiger auf die Stelle im StringBuffer wo "Hello" beginnt. Mit String s2= new String (s1); kann man eine zweite Stringvariable instanzieren. Die sollte ja nun den selben Inhalt wie s1 haben. Aber man kann machen was man will (s1 == s2; s1 == "Hello"; s2 == "Hello"), alle "Vergleiche" ergeben false (JDK 1.4.2_05). Lediglich "Hello" == "Hello" ergibt true. Klar... Hier vergleicht die JVM den absoluten Start der Zeichenkette "Hello" im StringBuffer mit... ähh... dem absoluten Start der Zeichenkette "Hello" im StringBuffer.

Als fortgeschrittener Java-Progger kommt man übrigens aus Performancegründen (laut Java-Handbuch 3.0) recht schnell von der vorwiegenden Benutzung der Klasse String weg, da intern ohnehin nur mit StringBuffer gearbeitet wird.

Man kann sich ja mal den Spaß machen, und sich einen Code erstellen, in dem Zig-Mal ein und die selbe Zeichenkette vorkommt, einige Vergleiche damit anstellen, diesen anschließend Kompilieren und sich den erstellten Bytecode in einem Hex-Editor ansehen bzw. nach der Zeichenkette suchen. Bei eigenen Versuchen konnte ich eine derartig verwendete Zeichenkette stets nur einmal finden.

 

[Bleiglanz]

richtig ist:

wenn ein String mit s = new String("hello") erzeugt wird, dann wird auf keinen Fall der Konstantenpool verwendet, sondern IMMER neuer Speicher verbraten!

deshalb wird new String("x") == new String("x") immer false liefern

wenn der String literal im Quelltext vorkommt

String s = "x";

dann wird "x" vom javac schon in den Stringpool gelegt...