File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

String.valueOf(X) vs. (String)X

 
Jacob Green
Greenhorn
Posts: 1
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What's faster assuming I'm 100% sure that X is a String?
 
William Brogden
Author and all-around good cowpoke
Rancher
Posts: 13048
6
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A cast is always going to be faster than a method call.

Less obvious questions can frequently be answered by looking at the source code.



Bill
 
Tim Holloway
Saloon Keeper
Pie
Posts: 17646
39
Android Eclipse IDE Linux
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
William Brogden wrote:A cast is always going to be faster than a method call.


Well, at least, if you're working in a naive environment. In Java, casts have to pass security constraints, and method calls can be optimized . And the net result may every well be either the exact same code, or even more efficient code on the method call (if the compiler decides it can bypass the security checks for a statically-defined type). So YMMV, depending on run environment and JVM.

So ALWAYS benchmark if it matters. And if it isn't a case where some sort of horrendous performance bottleneck has been detected, save your energy for higher-level optimizations where you'll get more performance with less effort.

The main difference, in fact, is that string.valueOf() can throw a NullPointerException, so the two code samples are not functionally equivalent!
 
William Brogden
Author and all-around good cowpoke
Rancher
Posts: 13048
6
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would like to point out that ALL method calls with an object reference have an implicit cast for security reasons so there is no way around it. Either explicit or implicit, a cast check will be performed.

Bill
 
Tim Holloway
Saloon Keeper
Pie
Posts: 17646
39
Android Eclipse IDE Linux
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
William Brogden wrote:I would like to point out that ALL method calls with an object reference have an implicit cast for security reasons so there is no way around it. Either explicit or implicit, a cast check will be performed.

Bill


Which is a point worth noting. Traditional strongly-typed languages would have ascertained the datatype from context at compile-time in many cases. But context can be defeated by patching code or jumping into the middle of otherwise secure code. Java is paranoid and doesn't assume that it can trust that the actual execution sequence and context is related to the source code.

But things like this can be done in some extremely gnarly ways. I think the Intel iapx432 CPU actually went so far as to put objects in their own private address spaces, so potentially, a class violation would manifest itself at the hardware level. And I don't even want to think of what IBM might do next on their zSeries hardware - they've already added Java-compatible (IEEE) floating point alongside their original floating point instructions and placed a good-sized chunk of the ANSI C library into microcode (zSeries is the antithesis of a RISC machine!).

So I've completely given on on trying to predict how low-level things get done anymore. There are just so many evil possibilities. Better just to try things and measure them. And expect that tomorrow, they'll be even more unpredictable.
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24204
34
Chrome Eclipse IDE Mac OS X
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Holloway wrote:
The main difference, in fact, is that string.valueOf() can throw a NullPointerException, so the two code samples are not functionally equivalent!


In a way, it's actually the other way around. The static method String.valueOf(s) will always return non-null, even if s is null, whereas (String) s will return null if s is null. For this reason I find I use String.valueOf() quite often, as it often makes sense to get rid of nulls this way in UI code.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic