Wrapper-klassen

[UdoKessler]

Moin,

bin jetzt beim Thema Wrapperklassen u hätte 1 o 2 Fragen..

Primitive Datentypen sind ja keine Objekte, dafür gibt es die Wrapperklassen.
Packt man die primitves in Wrapper, dann kann man Methoden wie z.B.
objektname.toString(); usw. anwenden.
Ist das der einzige Grund sie zu wrappen?
Denn ich könnte ja auch so schreiben: Integer.toString(primitive).

Und wenn ich das tue:

int i = 1;
String s = Integer.toString(i);

..wird dann intern das i ge-wrappt, in String verwandelt und das wrapper-objekt
danach gleich für den Garbage Collector freigegeben?
(Das i bleibt ja primitiv und s enthält "1", aber eine Referenz auf das (evtl intern
erstellte) i-objekt habe ich nicht.)




Dann schreibt er (Javainsel) weiter unten:

Zitat:
3.8.7 Autoboxing: Boxing und Unboxing

Der Compiler konvertiert nach festen Regeln, und auch die Operatoren ++, -- sind
erlaubt.

Integer i = 12; 
i = i + 1;                   // (1) 
i++;                         // (2) 
System.out.println( i );     // 14

Wichtig ist, dass weder (1) noch (2) das Original-Integer-Objekt mit der 12 ändern
(alle Wrapper-Objekte sind immuntable), sondern i nur andere Integer-Objekte für 13
und 14 referenziert.

Zitat-Ende


Frage: Was passiert dann mit dem ursprünglichen i-objekt, das 12 enthält? Garbage
Collector?


Noch eine Frage:
Ist >>Integer i = 1;<< und >>Integer i = new Integer( 1 );<< das selbe?


Danke schonmal
und frohe Ostern

Gruß
Udo

.

 

[Illuvatar]

Moin,

bin jetzt beim Thema Wrapperklassen u hätte 1 o 2 Fragen..

Primitive Datentypen sind ja keine Objekte, dafür gibt es die Wrapperklassen.
Packt man die primitves in Wrapper, dann kann man Methoden wie z.B.
objektname.toString(); usw. anwenden.
Ist das der einzige Grund sie zu wrappen?
Denn ich könnte ja auch so schreiben: Integer.toString(primitive).

Nein. Das wichtigste ist, dass man manchmal gerne primitive Datentypen an einer Stelle verwenden würde, an der nur Objekte erlaubt sind - zum Beispiel als Schlüssel in einer Map-Struktur. Das wäre ohne Wrapperklassen nicht möglich.

Und wenn ich das tue:

int i = 1;
String s = Integer.toString(i);

..wird dann intern das i ge-wrappt, in String verwandelt und das wrapper-objekt
danach gleich für den Garbage Collector freigegeben?
(Das i bleibt ja primitiv und s enthält "1", aber eine Referenz auf das (evtl intern
erstellte) i-objekt habe ich nicht.)

Äh - nein. Hier wird kein Objekt von einer Wrapperklasse erstellt. Die Methode Integer.toString erwartet ein int-Argument - kein Integer-Argument. Die Methode ist zwar in der Wrapperklasse untergebracht, aber statisch! Das ist nur eine Hilfsmethode, um einen int direkt in einen String zu wandeln - ohne irgendwelche Integer-Objekte.

Dann schreibt er (Javainsel) weiter unten:

Zitat:
3.8.7 Autoboxing: Boxing und Unboxing

Der Compiler konvertiert nach festen Regeln, und auch die Operatoren ++, -- sind
erlaubt.

Integer i = 12; 
i = i + 1;                   // (1) 
i++;                         // (2) 
System.out.println( i );     // 14

Wichtig ist, dass weder (1) noch (2) das Original-Integer-Objekt mit der 12 ändern
(alle Wrapper-Objekte sind immuntable), sondern i nur andere Integer-Objekte für 13
und 14 referenziert.

Zitat-Ende


Frage: Was passiert dann mit dem ursprünglichen i-objekt, das 12 enthält? Garbage
Collector?

Eigentlich - ja. In diesem Sonderfall allerdings nicht. Warum, siehe nächster Punkt.

Noch eine Frage:
Ist >>Integer i = 1;<< und >>Integer i = new Integer( 1 );<< das selbe?

Nein. >>Integer i = 1;<< ist das gleiche wie >>Integer i = Integer.valueOf(1)<<. Der Unterschied ist, dass >>new Integer(...)<< immer ein neues Objekt erstellt. Aus Performancegründen werden die Integer-Objekte bis 256 (256 ist geraten, das müsste ich nachschauen) immer gespeichert. Deshalb sollte man immer valueOf verwenden, weil eventuell kein neues Objekt erzeugt werden muss.
Edit: hab nachgeschaut - gecached werden Integer-Objekte für Werte von -128 bis 127

Danke schonmal
und frohe Ostern

Gleichfalls

 

[fjord]

Ist das der einzige Grund sie zu wrappen?

Nein. Wrapping von Primitiven wird zum Beispiel für generische Klassen benötigt. Maps, Sets usw. Ansonsten müsste man sie für alle Primitiven nochmal implementieren.

Und wenn ich das tue:

int i = 1;
String s = Integer.toString(i);

..wird dann intern das i ge-wrappt, in String verwandelt und das wrapper-objekt
danach gleich für den Garbage Collector freigegeben?

[highlight=java]public static String toString(int i) {
if (i == Integer.MIN_VALUE)
return "-2147483648";
int size = (i < 0) ? stringSize(-i) + 1 : stringSize(i);
char[] buf = new char[size];
getChars(i, size, buf);
return new String(0, size, buf);
}[/highlight]
Also kein Wrapping.

Och mann, zu spät. Dann kann ich ja auch aufhören weiterzuschreiben.

ps: Die Immutable Wrapper, wie unter anderem auch String, sollte man grundsätzlich nicht mit new erzeugen, weil man damit die Wiederverwendung der Objekte verhindert.

 

[UdoKessler]

Dankeschön!
Habt mir echt geholfen..

Endlich ergibt auch das Wort "valueOf" für mich einen Sinn

Ich muss mich da erst an all die neuen Dinge gewöhnen..denke ich.



Grüße
Udo

 

[hdi]

Noch eine Ergänzung zu diesem speziellen Verhalten von Wrapper-Objekten, da wir das neulich schon mal hatten:
Eig. erwartet man dass ein == Vergleich auf zwei Wrapper-Objekten niemals true ergibt, da sie Immutable sind. Bei Double-, Float- und Long-Objekten trifft das auch zu.
Boolean- und Byte- Objekte sind immer ==, wenn sie durch Boxing erstellt wurden.

Character, Short und Integer verhalten sich ähnlich zu Boolean und Bytes, aber mit Einschränkungen:
Bei Characters nur von \u0000 bis \u007f (letzeteres entspricht 127)
Bei Short und Integer nur von -128 bis 127

Noch eine Info am Rande, wo wir schon dabei sind: Beim == Vergleich von Wrapper und Primitiv wird der Primitiv aus dem Wrapper gezogen und mit dem Primitiv verglichen. D.h.
3 == new Integer(3) ergibt true

mfg

 

[fjord]

Eig. erwartet man dass ein == Vergleich auf zwei Wrapper-Objekten niemals true ergibt, da sie Immutable sind. Bei Double-, Float- und Long-Objekten trifft das auch zu.

Warum sollte man das gerade von Immutable Objekten erwarten? Die Aussage stimmt so auch nicht. [highlight=java]Long a = 5L;
Long b = 5L;
System.out.println(a == b);
// gibt true aus[/highlight]

 

[SlaterB]

noch besser:
System.out.println(a == a);

 

[hdi]

Hey... dieses besch** "Study-Guide" kotzt mich so an Ich hab jetzt schon soviel falsches dadurch gelernt... Die schreiben eine Sache hin, und man weiss nie worauf die sich grad beziehen. Oft meinen sie eine Aussage nur im jetzigen Kontext, oft aber nicht, und man weiss nie, was jetzt zutrifft. Das ist mir jetzt echt schon mit dem 10.Thema passiert. Verdammt noch mal -.- Was ist das für ein Schrott. Ich hab grad nachgelesen, dort steht eiskalt nur:

Two wrapper objects of the following classes will always be == true, if they have the same value and were created through boxing:

Boolean, Byte, Character, Short, Integer.

Feritg, dann beginnt ein neues Kapitel...
Das hieß für mich: Long, Double und Float legen dieses Verhalten nicht an den Tag.
Tolle Sache, das ist jetzt schon so oft passiert, ich glaube langsam dieses Buch bereitet mich null auf die Prüfung vor. Ich denke ich verstehe alles, weil ich es hinnehme wie es dort steht, und musste jetzt schon so oft feststellen dass das einfach nur Bullshit ist, der da steht. Total aus dem Kontext gerissen oder unvollständig. Geil.... Ich lerne da zwar Neues, aber nur Falsches scheint es mir

Sorry also für die falsche Aussage.. Ich glaube ich werd Ebenius dafür bezahlen müssen dass er sich am Ende meine Zusammenfassug anschaut und den ganzen Mist korrigiert, den ich mir da aufgeschrieben hab :bahnhof:

 

[UdoKessler]

@hdi

Darfst Du denn nicht ein anderes "normales" Buch zum lernen benutzen?

Sorry also für die falsche Aussage..

Kein Problem, die Anderen habens ja aufgeklärt!
Ich nehm das keinem Übel..hab selbst
auch schon genug Stuss gepostet in meinem Leben

Gruß
Udo

 

[hdi]

Na klar kann ich ein anderes Buch nehmen. Ist ja keine Schule, nur ein Test. Aber in normalen Lehrbüchern über Java stehen solche Dinge natürlich nicht. SCJP heisst JLS fressen... Und genau das wäre ne Alternative, die JLS. Aber ernthaft: Wer kann sich das denn von vorne bis hinten drücken? Immerhin ist das kein Buch, sondern eine Dokumentation. Ich werd das Study Guide durchmachen, und am Ende nochmal alles in der Praxis testen müssen, um Verständnisfehler zu entdecken.