Question

When the Java developers make design decisions, they usually follow ‘best practices’ about code maintainability and what not. So I was surprised to find the following situation in the String class source code (The comments are mine, not theirs obviously).

/* Makes sense, use the appropriate class for this */
public static String valueOf(int i) {
    return Integer.toString(i, 10);
}

/* Makes sense, use the appropriate class for this too */
public static String valueOf(float f) {
return Float.toString(f);
}

/* Magic values "true" and "false"? Seriously? */
public static String valueOf(boolean b) {
return b ? "true" : "false";
}

This made me think that for some reason it perhaps might not be defined in Boolean class, or that Boolean references String. Again, I am surprised to find this method is duplicated.

/* Identical code to String */
public static String toString(boolean b) {
    return b ? "true" : "false";
}

Now, I understand that it’s highly unlikely the canonical representation of boolean values is likely to change. But how many times have the people who send us (as developers) send us requirements say “Oh, this won’t change – it’s set in stone!” and yet, after a certain amount of time, they come back and say “We need this change, and we need it now!” and hang up before you can tell them they said it would never change.

Is there any particular reason they would do this? I know that sentence makes it sound like it’s murder or something, but still. Am I the only one surprised by this?

Answer 1

"true" and "false" are mandated by the language itself; thus in this case it’s relatively safe to hardcode the string values.

JLS 4.2.5 The boolean Type and boolean Values

… will convert the boolean operand to a String (either "true" or "false") …

Similarly, the language specifies e.g. null references becomes "null" during string conversion.

JLS 15.18.1.1 String Conversion

If the reference is null, it is converted to the string "null" (four ASCII characters n, u, l, l)

Generally it’s best not to hardcode constants all over the code base, but when the language guarantees what the constants should be, this becomes less of a problem.

---

Here’s a snippet from OpenJDK for AbstractStringBuilder:

public AbstractStringBuilder append(boolean b) {
    if (b) {
        ensureCapacityInternal(count + 4);
        value[count++] = 't';
        value[count++] = 'r';
        value[count++] = 'u';
        value[count++] = 'e';
    } else {
        ensureCapacityInternal(count + 5);
        value[count++] = 'f';
        value[count++] = 'a';
        value[count++] = 'l';
        value[count++] = 's';
        value[count++] = 'e';
    }
    return this;
}

Note that StringBuilder extends AbstractStringBuilder.