All | About | AJAX | BASIC | Creator | General | Java | JavaFX | NetBeans | Personal | Posse | Ruby
« Dr. Dobbs Journal... | Main | NetBeans plugins I... »

20050608 Wednesday June 08, 2005

Converting an int to a String

I came across this tip in a blog referenced from Eric's linkblog.

The author mentions that you can convert from an int to a String like this: 

   int one = 1;
   String str = one + "";
And he calls that cute!

I disagree - I think that's ugly (and as he points out it's less efficient).

There's a clean way to do this, not listed in his blog: 

   int one = 1;
   String str = Integer.toString(one);
Nice efficient bytecode too: 
   0:   iconst_1
   1:   istore_1
   2:   iload_1
   3:   invokestatic    #2; //Method java/lang/Integer.toString:(I)Ljava/lang/String;
   6:   astore_2
   7:   return
and there are variations of the method which lets you convert using another base - so you can convert to hex using Integer.toString(one, 16) for example.

(String.valueOf(int) will turn around and call the above method by the way.)

(2005-06-08 22:43:59.0) Permalink Comments [5]

Comments:

I do like the concatenation because, assuming the line compiles, everyone understands what it does and you don't need to remember an API. I don't see a big performance hit either. But I can see why you don't and your approach is certainly more "elegant".
-Alexis

Posted by Alexis MP on June 09, 2005 at 01:30 AM PDT #

Well, the most elegant and logical would be int foo = 1;
String text = foo.toString();
but that doesn't work, of course. AutoBoxing allows to write somehow similar code: String fooStr = ((Integer)foo).toString(); Well... that's neither elegant nor efficient (if foo is outside the cached range of values).

I think this is a bit of an oversight in the Java language design, the same with arrays, where you can call array.toString, array.length, but not array.copy... Just more inconsistencies to remember...

On weirdness with primitives and Strings If you're a new dev and find
boolean Boolean.getBoolean(String)
expect the unexpected...

Posted by murphee on June 09, 2005 at 03:09 AM PDT #

When you write String str = myOtherString + x + " static string"; the compiler should be smart enough to turn it into effecient code using StringBuilder. On that same note, shouldn't the compiler be smart enough to turn String str = 0 + ""; into the appropriate bytecode since this shortcut has been around for years?

Posted by Tom on June 09, 2005 at 05:02 AM PDT #

(I'm the author of the original tip)

I actually have traditionally used Integer.toString(intValue). However, when I was witing that thing I looked at the bytecode of the (intValue + "") conversion, noticed it used String.valueOf() and wrote it that way.

I don't actually see a lot of difference between the two.

Re Tom's comment: The Eclipse 1.4 compiler will actually generate better bytecode for the following: String str = 1 + ""; (it won't create String buffers etc).

Posted by Nick Lothian on June 09, 2005 at 04:55 PM PDT #

Thank you all for your comments. Let me just qualify what I meant. Clearly, I enjoy type conversion when it's used logically, like this: int count = 10; String message = "Your basket contains " + count + " items"; This code is readable. And -that- is my number one goal: clear and readable code. Even if that code is harder to construct in the first place - requiring programmer knowledge of available APIs, or requiring well thought out variable names. I wish I hadn't included the bytecode dump, since from that perspective, choosing shorter names is also a performance advantage - smaller class footprint, faster symbol lookup etc. Code readability is very important to me. And if you're -just- doing an integer conversion, then String s = i + ""; is mysterious - a reader not familiar with this pattern will be slightly puzzled. String s = Integer.toString(i); will immediately be able to read this as an integer string conversion. So yeah, I agree with your comments that the compilers should optimize all these examples down to the essential bytecodes, but at the end of the day, my objection is with the resulting .java code.

Posted by Tor Norbye on June 10, 2005 at 03:19 PM PDT #

Post a Comment:

Comments are closed for this entry.