Using static variables for Strings

Question

below content is taken from Best practice: Writing efficient code but i didn't understand why

private static String x = "example";

faster than

private static final String x ="example";

Can anybody explain this.

Using static variables for Strings

When you define static fields (also called class fields) of type String, you can increase application speed by using static variables (not final) instead of constants (final). The opposite is true for primitive data types, such as int.

For example, you might create a String object as follows:

private static final String x = "example";

For this static constant (denoted by the final keyword), each time that you use the constant, a temporary String instance is created. The compiler eliminates "x" and replaces it with the string "example" in the bytecode, so that the BlackBerry® Java® Virtual Machine performs a hash table lookup each time that you reference "x".

In contrast, for a static variable (no final keyword), the String is created once. The BlackBerry JVM performs the hash table lookup only when it initializes "x", so access is faster.

private static String x = "example";

You can use public constants (that is, final fields), but you must mark variables as private.

Answer 1

the text explains it, just read it.

but to reword it: Its faster because it is. The way blackberry jvm is made its better to use the non final version. Its like that because its designed in that fashion

Answer 2

There is a runtime String Literal Pool. When you create the Strings as Final the JVM creates a copy of the String each time you use it. When the String is non-final it is inserted into the String Literal Pool the first time you create it and then after that it is just looked up from the pool, this avoids copies of the Strings.

Answer 3

This is the specifics of the Blackberry VM. Other VM might do it differently.

Side Note: do not pay too much attention to the optimization until you actually run into the performance issues (this is called "premature optimization") 'cause if you do it is highly possible that performance is leaked in the place where you would never expect it to.

Answer 4

I wasn't aware of this, but it makes sense to me:

The JVM has an internal String Literal Cache. Everytime you create a String by using a literal, the JVM has to look for it in the cache and if it isn't there, store it.

Now a compiler can inline a final variable with a String literal, because it is known at compile time and it seems to be a good idea for performance.

So your code:

static final String CONST = "myconst";
...
if (CONST.equals(aVar))
...
case CONST
...

is rewritten by the compiler to:

static final String CONST = "myconst";
...
if ("myconst".equals(aVar))
...
case "myconst"
...

If the JVM implementation isn't clever enough, it needs to look up "myconst" three times in this example.

When you don't mark CONST as "final", the compiler can't "optimize" it since the variable can change at runtime. Your code would be compiled 1:1 and the JVM only needs to look for the Object at the variable.

btw: Bad JVM implementations shouldn't define your coding style. "final" gives a lot of safety, so as long as it doesn't really hit your performance: Don't care about if it increase or decrease you speed - its different for the next JVM anyhow

Answer 5

wow!

because BlackBerry® Java® Virtual Machine is retarded?

If a Java VM has huge penalty for using final variables, which is an important language concept, it is retarded.