Compile-Time Versus Runtime Resolution of Strings
For optimized use of
String
s, you should know the difference between
compile-time resolution of String
s and runtime
creation. At compile time, String
s are resolved to
eliminate the concatenation operator if possible. For example, the
line:
String s = "hi " + "Mr. " + " " + "Buddy";
is compiled as if it read:
String s = "hi Mr. Buddy";
However, suppose you defined the String
using a
StringBuffer
:
String s = (new StringBuffer( )).append("hi "). append("Mr. ").append(" ").append("Buddy").toString( );
Then the
compiler cannot resolve the
String
at compile time. The result is that the
String
is created at runtime along with a
temporary StringBuffer
. The version that can be
resolved at compile time is more efficient. It avoids the overhead of
creating a String
and an extra temporary
StringBuffer
, as well as avoiding the runtime cost
of several method calls.
However, when an expression involving String
concatenation cannot be resolved at compile time, the concatenation
must execute at runtime. This causes extra objects to be generated.
For example, consider the following method:
public String sayHi(String title, String name) { return "hi " + title + " " + name; }
The String
generated by this method cannot be
resolved at compile time because the variables can have any value.
The compiler is free to generate code to optimize the
String
creation, but it does not have to.
Consequently, the String
-creation line could be
compiled as:
return (new StringBuffer( ...
Get Java Performance Tuning now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.