Integer.toString(int i) vs. String.valueOf(int i)

  • Themenstarter Themenstarter hüteüberhüte
  • Beginndatum Beginndatum
H

hüteüberhüte

Gast
Welches sollte man nehmen? Was ist evtl. besser?

valueOf ruft intern toString auf :shock:

Heißt das lieber Integer.toString(int i) verwenden?
 
Zu Zeiten, in denen es um jeden Taktzyklus ging, wohl eher das, welches intern nicht weiterdelegiert.
Integer.toString() hat gegenüber String.valueOf() noch den Vorteil, dass man auch Ausgaben in anderen Zahlenformaten hinbekommt. Ansonsten ist's egal.
 
Zuletzt bearbeitet von einem Moderator:
Nimm Integer.toString, da sparst du 2 Aufrufe und 2 Vergleiche wenn ich das im Java-Source gerade richtig geblättert habe (Effektiv ist es wohl egal, solange du das nicht extrem oft ausführst lohnt sich tuning auf so einer Ebene nicht).

Gruß
 
???:L Jep... <Object>.toString() existiert ja leider für Primitivtypen nicht. :lol:
Jein. Diese Methoden sind alle statisch, und es gibt hinreichend viele solcher Methoden derart, dass man im Java-Quelltext jeden Wert beliebigen Typs als erstes und einziges Argument übergeben kann, eben auch primitive Werte und sogar null (was man so von [c]toString()[/c] nicht behaupten kann).

BTW: Ich meide diese [c]valueOf()[/c]-Methoden und verwende lieber z.B. [c]Integer.toString()[/c].

Ark
 
???:L Jep... <Object>.toString() existiert ja leider für Primitivtypen nicht. :lol:
Keine Ahnung, was du damit gemeint hast.

Ich wollte nur darauf hinaus, dass man einfach immer
Code:
String.valueOf()
verwenden kann, egal ob
Code:
int
,
Code:
double
etc. Alternative wäre halt
Code:
Integer.toString()
,
Code:
Double.toString()
etc.

Eigentlich war meine Antwort auch leicht satirisch gemeint, weil es total wumpe ist, wie man es nun macht. Hauptsache nicht so ein Mist wie
Code:
int + ""
.
 
Eigentlich war meine Antwort auch leicht satirisch gemeint, weil es total wumpe ist, wie man es nun macht. Hauptsache nicht so ein Mist wie
Code:
int + ""
.
Dann hebe die Satiere doch das nächste mal mit 'nem ???:L ... :lol: heraus, so wie ich 😉.
Wenigstens sind wir uns in dieser Hinsicht ja einig.
Aber noch mal zum tieferen Sinn des Humors. Jede dieser String.valueOf() Methoden, ausser die mit den Chararrays ruft etwas mit toString() auf, deswegen ist's in den meisten Fällen auch vollkommen egal. Hotspot findet diese "valueOf()"s bei längerer Laufzeit und exessiver Nutzung (wenn nicht sogar sofort) ohnehin und optimiert dann entsprechend.
Die Klasse Object hat eine solch' statische Methode nicht, weil diese sonst jede Klasse zwangsvererbt bekäme.

BTW: Ich meide diese [c]valueOf()[/c]-Methoden und verwende lieber z.B. [c]Integer.toString()[/c].
Das kommt auch auf die Situation an, z.B. wenn der Typ der Variable nicht feststeht -> valueOf(). Was bleibt einem übrig.
 
Zuletzt bearbeitet von einem Moderator:
Jede dieser String.valueOf() Methoden, ausser die mit den Chararrays ruft etwas mit toString() auf, deswegen ist's in den meisten Fällen auch vollkommen egal. Hotspot findet diese "valueOf()"s bei längerer Laufzeit und exessiver Nutzung (wenn nicht sogar sofort) ohnehin und optimiert dann entsprechend.
Ist ja im Prinzip das Gleiche mit
Code:
SwingUtilities.invokeLater()
. Das delegiert auch nur zu
Code:
EventQueue.invokeLater()
.

Das kommt auch auf die Situation an, z.B. wenn der Typ der Variable nicht feststeht -> valueOf(). Was bleibt einem übrig.
???:L if-else mit instanceof :lol:
Nun ja, wenn der Typ nicht feststeht, wird es ja eine Referenzvariable sein. Also könnte man auch einfach
Code:
toString()
nehmen (von
Code:
null
mal abgesehen).
 

Zurück
Oben