18

Is conversion to String in Java using 

"" + <int value>

bad practice? Does it have any drawbacks compared to String.valueOf(...)?

Code example:

int i = 25;
return "" + i;

vs:

int i = 25;
return String.valueOf(i);

Update: (from comment)

And what about Integer.toString(int i) compared to String.valueOf(...)?

MicSim
  • 26,265
  • 16
  • 90
  • 133
  • And what about `Integer.toString(int i)`? (will not compile if you change `i` to another type which might be a good thing or not) – Pascal Thivent Oct 15 '09 at 14:45
  • @Pascal Thivent: see my answer, it looks like `Integer.toString(int i)` is the best of them all! – Kip Oct 15 '09 at 14:58
  • (at least from performance, a readability argument could still be for String.valueOf(), since the performance difference is negligible) – Kip Oct 15 '09 at 15:01
  • Integer.toString(i, 10) is equivalent to String.valueOf(i) – Kevin Oct 15 '09 at 17:18

8 Answers8

35

I would always prefer the String.valueOf version: mostly because it shows what you're trying to do. The aim isn't string concatenation - it's conversion to a string, "the string value of i".

The first form may also be inefficient - depending on whether the compiler spots what you're doing. If it doesn't, it may be creating a new StringBuffer or StringBuilder and appending the value, then converting it to a string.

Funnily enough, I have an article about this very topic - written years and years ago; one of the first Java articles on my web site, IIRC.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
11

There is also Integer.toString(int i), which gives you the option of getting the string as a hex value as well (by passing a second param of 16).

Edit I just checked the source of String class:

public static String valueOf(int i) {
  return Integer.toString(i, 10);
}

And Integer class:

public static String toString(int i, int radix) {
  if (radix < Character.MIN_RADIX || radix > Character.MAX_RADIX)
    radix = 10;

  /* Use the faster version */
  if (radix == 10) {
    return toString(i);
  }
  ...

If you call String.valueOf(i), it calls Integer.toString(i, 10), which then calls Integer.toString(i).

So Integer.toString(i) should be very slighty faster than String.valueOf(i), since you'd be cutting out two function calls. (Although the first function call could be optimized away by the compiler.)

Of course, a readability argument could still be made for String.valueOf(), since it allows you to change the type of the argument (and even handles nulls!), and the performance difference is negligible.

Kip
  • 107,154
  • 87
  • 232
  • 265
  • +1 for checking the source and reporting back. Admittedly, may be considered premature optimization, but good information nonetheless. – RHSeeger Oct 15 '09 at 15:49
10

Definitely use String.valueOf(i).

Although I'm not sure of the optimizations on the compiler side, worst case scenario if you use "" + :

  1. "" creates a new empty string.
  2. "" + creates a StringBuilder (Java 1.5-16)
  3. "" is appended to the StringBuilder, then

In other words, there is a lot of overhead that occurs if you use string addition. This is why it is not recommended to use the + operator on strings in loops. In general, always use Boolean.valueOf, Integer.valueOf, String.valueOf... etc, when possible. You'll save both on memory and on overhead.

Malaxeur
  • 5,973
  • 1
  • 36
  • 34
  • "" doesn't create a new empty string on every iteration. There will be a single string for all the occurrences of "". But yes, unless the compiler catches it you'll end up with an extra StringBuilder. – Jon Skeet Oct 15 '09 at 14:33
  • The first empty quote will be interned, so there will only ever be one (this is a JLS thing, not just an optional optimization). – Yishai Oct 15 '09 at 14:33
  • The issue with + on strings in loops has nothing to do with this. – Michael Borgwardt Oct 15 '09 at 14:35
  • Ah, I wasn't aware that the literal was interned. I was under the assumption that unless you explicitly call .intern, no string literals are interned. Regardless, there's additional overhead on the internalizing + extra overhead of an empty string (for nothing) in this case... which we're all in agreement with. – Malaxeur Oct 15 '09 at 14:37
  • The issue with + on strings in loops has nothing to do with this. – Michael Borgwardt Oct 15 '09 at 14:37
  • The interning doesn't have any overhead on a per invocation basis - it's done on class load. That wouldn't bother me at all. It's the creation of a pointless StringBuilder etc that's the problem. – Jon Skeet Oct 15 '09 at 14:50
  • It's true that only one instance of the empty string will be created, but that's still one wasted creation of a string. Well, maybe in a non-trivial program you're going to create an empty string for something somewhere anyway. – Jay Oct 15 '09 at 14:56
3

Regardless of any performance considerations I think the first variant is really ugly. IMHO it's a shame that this kind of "dynamic casting" is even possible in Java.

Daniel Rikowski
  • 71,375
  • 57
  • 251
  • 329
1

Yes, it is IMHO a bad practice.

It would require to memory allocations (unless compiler and/or JIT optimize them). What's more, it will make less evident, what this code tries to do.

elder_george
  • 7,849
  • 24
  • 31
0

Personally I dislike the style of "" + i, but that is really a preference/coding standards thing. Ideally the compiler would optimize those into equivalent code (although you would have to decompile to see if it actually does), but technically, without optimization, "" + i is more inefficient because it creates a StringBuilder object that wasn't needed.

Yishai
  • 90,445
  • 31
  • 189
  • 263
0

Right off the bat all I can think of is that in the your first example more String objects will be created than in the second example (and an additional StringBuilder to actually perform the concatenation).

But what you are actualy trying to do is create a String object from a int not concatenate a String with an int, so go for the:

String.valueOf(...);

option,

So yes your first option is bad practice!

Ron Tuffin
  • 53,859
  • 24
  • 66
  • 78
0

I wonder what is best for static final variables contributing to compile-time constants:

public static final int VIEW_TYPE_LABEL_FIELD = 1;
public static final int VIEW_TYPE_HEADER_FIELD = ;

...

List <String[]> listViewInfo = new ArrayList<>();

listViewInfo.add(new String[]{"Label/Field view", String.valueOf(VIEW_TYPE_LABEL_FIELD)});
listViewInfo.add(new String[]{"Header/Field view", "" + VIEW_TYPE_LABEL_FIELD});

The compiler can potentially replace the String expressions with a constant. Is one or the other more recognizable as a compile-time constant? Maybe easier for the ("" + ..) construct?

sb4
  • 169
  • 1
  • 6