static final String = "something" -- does the static make sense?

Question

static final String = "something";

I was wondering if such a declaration has some kind real sense in Java. I've found it thousands of time within the code but studying and playing with strings I've learnt that does not matter how many times you declare a String object: if some class before yours declared this string this is pooled and reused (I'm talking about String created without explicit constructor invocation)

public class StringCompare {   
    private void toCompare(String h) {
        String x = "hello";
        System.out.println( x == h);
    }

    public void compare() {
        String h = "hello";
        toCompare(h);
    }      
}

This code, in fact, prints true when calling compare so the 2 variables are referencing the same object. Said that a final variable can't be redefined, the static word is completely useless in this case. Am I missing the point?

Couple of more things:

1 - Why explicit call to String constructor won't cause the String to be pooled? Same code above using a new String("hello") print false.

2 - Is the pooling behaviour reserved to Strings? There are some other immutable objects (like BigInteger) but I think these are not pooled ... why?

Thanks, Carlo

Answer 1

There are a few reasons why developers use this pattern, even though your analysis of the runtime behavior and its use the string pool is correct.

1. It communicates the developers intent more cleanly. Specifically the string now has a name that is hopefully more clear than the constant, and it communicates the runtime behaviour that not everybody is aware of (or they forget from time to time).
2. If the developer wants to change the value within the source file, and it has been used in multiple places then there is only one place to make that change.
3. Once the decision to use a variable has been made, the keyword static will mean that the memory usage is lower. That is, there is only one field used to store the ref rather than one field per instance of the object.

As for your follow on questions:

1. Q: Why explicit call to String constructor won't cause the String to be pooled? Same code above using a new String("hello") print false.

Because the string pool is only used for string literals, as described by the JLS and invoking a constructor is not classified as a string literal.

2. Q: Is the pooling behaviour reserved to Strings?

The string pool is only used for string literals, but there is of course other caches for different use cases. The most obvious one that jumps to mind is the int cache used to optimize auto boxing of ints.

Answer 2

Even if the static doesn't give you a memory benefit in this case, you can still access the field in a static way, so you don't need an instance. For example, you frequently use some URIs, so you create the following class:

public class Uris
{
    public static final String GOOGLE = "http://google.com";
    public static final String BBC = "http://bbc.co.uk";
}

Using static, you can just use Uris.GOOGLE instead of new Uris().GOOGLE.