Unterschied Integer.toString(x) und x.toString()

[matze86]

Hallo, ich bin jetzt drauf gestoßen, dass ich in einer Methode nur Integer.toString(x) statt x.toString() verwenden kann. Was ist da der Unterschied?
x steht für ein Integer.

Ich übergebe in einer Methode ein Integer und möchte den in einen String später umwandeln.
Gruß

 

[temi]

Kein Unterschied. Die Methode Integer.toString() ruft intern die Metode Integer.toString(int) auf.

Allerdings solltest du, wo immer möglich, den primitiven Datentyp int, anstatt von Integer (die Wrapper-Klasse) verwenden, um die unnötige Erzeugung von Objekten zu vermeiden.

 

[kneitzel]

Jetzt war @temi schneller.

Nur eine Ergänzung bezüglich

dass ich in einer Methode nur Integer.toString(x) statt x.toString() verwenden kann.

Wenn die Variable vom Typ Integer ist, dann kannst Du auch x.toString() verwenden. Wenn x aber nur ein int ist, dann ist es ein Value Typ und damit ist x keine Referenz auf eine Instanz. Keine Referenz bedeutet: Es lassen sich darauf keine Methoden aufrufen.

 

[temi]

Dann aber auch noch eine Ergänzung dazu

Wenn die Variable vom Typ Integer ist, dann kannst Du auch x.toString() verwenden. Wenn x aber nur ein int ist, dann ist es ein Value Typ und damit ist x keine Referenz auf eine Instanz. Keine Referenz bedeutet: Es lassen sich darauf keine Methoden aufrufen.

In dem Fall bietet sich dann wieder die statische Methode Integer.toString(int) an, um den primitiven Typen in einen String zu wandeln.

 

[matze86]

Anbei der Beispielcode, wo nur Integer.toString(x) funktionier (siehe Zeile 4).

class Zahl{
    String tester(int x){
        String s;
        s = Integer.toString(x); //x.toString() geht nicht
        return s;}
    }

public class Test {
    public static void main(String[] args) {
        Zahl y = new Zahl();
        String ff;
        ff = y.tester(5);
       
        System.out.println(ff);
    }
}

 

[kneitzel]

Anbei der Beispielcode, wo nur Integer.toString(x) funktionier (siehe Zeile 4).

Das war ja, was ich bei der Erläuterung gemeint habe: Der Parameter x ist vom Typ int.

Du kannst Methoden doch nur auf Referenzen aufrufen, da Referenzen auf Objekte/Instanzen verweisen! Wenn Du als Typ Integer hättest, dann könntest Du da auch toString aufrufen:
String tester(Integer x){

Aber dann kannst Du d auch null übergeben, also evtl. nicht das, was Du willst.

Generell gibt es auch eine automatische Umwandlung wenn bei der Addition ein Parameter ein String ist. Also ein einfaches
"" + x reicht zur einfachen Umwandlung bereits.

 

[matze86]

Ahh ok. Was ist der Unterschied zwischen int und Integer? Ich dachte es war das gleiche.

 

[temi]

Ahh ok. Was ist der Unterschied zwischen int und Integer? Ich dachte es war das gleiche.

Das steht auch schon ganz oben: int ist der primitive Integer-Typ und Integer ist eine Wrapperklasse dafür (benötigt man z. B. in List<>).

 

[matze86]

OK danke. wieder was gelernt.

 

[temi]

Aber aufpassen! Das folgende funktioniert:

Integer sum = 0;
for (int i = 0; i < 10000; i++) {
    sum += i;
}

Aber es wird jedesmal, wenn sum berechnet wird, ein neues Objekt erzeugt. Das macht den Code unnötig langsam.

 

[mrBrown]

Generell ist für sowas String.valueOf meistens am sinnvollsten, das ist für alle Typen überladen und ist nullsafe, was für die Methoden von Integer nicht gilt.

 

[matze86]

Generell ist für sowas String.valueOf meistens am sinnvollsten, das ist für alle Typen überladen und ist nullsafe, was für die Methoden von Integer nicht gilt.

Also soll man lieber String.valueOf(x) statt Integer.toString(x) verwenden?

 

[temi]

Generell ist für sowas String.valueOf meistens am sinnvollsten, das ist für alle Typen überladen und ist nullsafe, was für die Methoden von Integer nicht gilt.

[CODE lang="java" title="Implementierung von valueOf der Klasse String"]
public static String valueOf(int i) {
return Integer.toString(i);
}[/CODE]

Aber @mrBrown hat schon recht damit. Es gibt halt viele Wege, die nach Rom führen und nicht immer ist einer der Beste.

 

[mrBrown]

[CODE lang="java" title="Implementierung von valueOf der Klasse String"]
public static String valueOf(int i) {
return Integer.toString(i);
}[/CODE]

Ich weiß

Und jetzt ändert irgendwer den Typen zu Integer, läuft durch Autoboxing weiter ohne Probleme, bis dann null übergeben wird und die NPE fliegt.


Und mir String.valueOf hat man zusätzlich den Vorteil, das es überall gleich ist, wenn man sich darauf festlegt vermeidet man den Mischmasch aus 4 verschiedenen Varianten pro Typ.

 

[temi]

Ja. Da ist noch ne Annotation @NotNull und @Contract(pure=true). Hab jetzt nicht geschaut, was das bewirkt.

 

[mrBrown]

Ja. Da ist noch ne Annotation @NotNull und @Contract(pure=true). Hab jetzt nicht geschaut, was das bewirkt.

Bewirken tun die nichts, das sind nur IntelliJs Hinweise, dass die Methode niemals null zurück gibt (was bei toString uä auch Unsinn wäre) und niemals den Zustand verändert.

 

[Mart]

Ja. Da ist noch ne Annotation @NotNull und @Contract(pure=true). Hab jetzt nicht geschaut, was das bewirkt.

eine annotation tut an sich nichts "selbst" .. zb die FXML annotation ist einfach nur die klasse und sonst nix drin, diese wird dann durch reflektion und sonst was einen "sinn"gegeben

 

[thecain]

eine annotation tut an sich nichts "selbst" .. zb die FXML annotation ist einfach nur die klasse und sonst nix drin, diese wird dann durch reflektion und sonst was einen "sinn"gegeben

Naja, abgesehen davon das beides Annotationen sind, haben diese mit @FXML nicht viel gemeinsam

 

[mihe7]

Und jetzt ändert irgendwer den Typen zu Integer, läuft durch Autoboxing weiter ohne Probleme, bis dann null übergeben wird und die NPE fliegt.


Und mir String.valueOf hat man zusätzlich den Vorteil, das es überall gleich ist, wenn man sich darauf festlegt vermeidet man den Mischmasch aus 4 verschiedenen Varianten pro Typ.

Genau aus dem Grund verwende ich String.valueOf() in der Regel ungern Ich will eine Exception und keinen String "null", der dann still und heimlich irgendwo landet und dann irgendwo/-wann anders zum Problem führt (ja, ich weiß, sollte beim Test auffallen).

 

[mrBrown]

Genau aus dem Grund verwende ich String.valueOf() in der Regel ungern Ich will eine Exception und keinen String "null", der dann still und heimlich irgendwo landet und dann irgendwo/-wann anders zum Problem führt (ja, ich weiß, sollte beim Test auffallen).

Stimmt, ist je nachdem wo man das benutzt vielleicht doch sinnvoller.


Ich hab zu viel an meinen üblichen Anwendungsfall gedacht, das ist meistens in toString oder Log-Ausgaben oder an ähnlichen "internen" Stellen, da will ich explizit keine Exception. Aber ja, an allen anderen Stellen würd ich die NPE auch bevorzugen.

 

[kneitzel]

Wobei ich immer einfach kurz etwas schreibe wie "" + x - das ist deutlich kürzer als ein String.valueOf(x) und von der Logik her gleich ist:

JLS 5.1.11

Any type may be converted to type String by string conversion.

A value x of primitive type T is first converted to a reference value as if by giving it as an argument to an appropriate class instance creation expression (§15.9):

Now only reference values need to be considered:

• If the reference is null, it is converted to the string "null" (four ASCII characters n, u, l, l).
• Otherwise, the conversion is performed as if by an invocation of the toString method of the referenced object with no arguments; but if the result of invoking the toString method is null, then the string "null" is used instead.

String.valueOf(Object)

if the argument is null, then a string equal to "null"; otherwise, the value of obj.toString() is returned.

Der Unterschied, der hier halt intern ist, ist die Erstellung einer Instanz, die bei der String Concatenation auftritt (so wirklich exakt so vorgegangen wird und intern nicht einfach ein String.valueOf ausgeführt wird. Hier würde ich prinzipiell bei der genauen Implementation diese Optimierung erwarten. Aber ich habe jetzt kein Bytecode analysiert.)

 

[Mart]

Wobei ich immer einfach kurz etwas schreibe wie "" + x - das ist deutlich kürzer als ein String.valueOf(x) und von der Logik her gleich ist:

JLS 5.1.11


String.valueOf(Object)


Der Unterschied, der hier halt intern ist, ist die Erstellung einer Instanz, die bei der String Concatenation auftritt (so wirklich exakt so vorgegangen wird und intern nicht einfach ein String.valueOf ausgeführt wird. Hier würde ich prinzipiell bei der genauen Implementation diese Optimierung erwarten. Aber ich habe jetzt kein Bytecode analysiert.)

es ist jedoch ein unterschied zwischen

String s = 3 +3 +"";
und String s = "" + 3 +3;

wobei hier das string value of eindeutiger wäre was man möchte

 

[kneitzel]

wobei hier das string value of eindeutiger wäre was man möchte

Daher ist das Pattern bei mir immer "" + .... - dann ist es immer klar auf Grund der Ausführung der Operatoren von Links nach Rechts.

Und ich mag halt keine zu langen Zeilen. Aber wie @mrBrown ja auch den typischen Anwendungsfall für sowas beschrieben hat:

Ich hab zu viel an meinen üblichen Anwendungsfall gedacht, das ist meistens in toString oder Log-Ausgaben oder an ähnlichen "internen" Stellen,

Wenn es um Ausgaben geht, ist es in Projekten oft so, dass eben eine Nachricht aus Ressourcen zusammen gesetzt wird um die Ausgaben anzupassen. Und da läuft es dann bei mir auf java.text.MessageFormat hinaus. (Hier wird auf Argumente über die Position zugegriffen. Es können also Werte in beliebiger Reihenfolge und Anzahl verwendet werden. Bei Übersetzungen / Anpassungen an Kundenwünsche kann das durchaus Sinnvoll sein.) Und da wird dann auch nichts in String umgewandelt, denn da will man ggf. auch Formatierungen haben.