Строковое поведение исходного класса несовместимо между типами

Question

Когда разработчики Java принимают проектные решения, они обычно следуют «лучшим практикам» в отношении поддержки кода, а что нет. Поэтому я был удивлен, обнаружив следующую ситуацию в исходном коде класса String (комментарии мои, а не их, очевидно).

/* 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";
}

Это заставило меня подумать, что по какой-то причине, возможно, он не определен в булевом классе или что булевские ссылки ссылаются на String. Опять же, я удивлен, обнаружив, что этот метод дублируется.

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

Теперь я понимаю, что маловероятно, что каноническое представление логических значений может измениться. Но сколько раз люди, которые присылают нам (как разработчики), присылают нам требования, говорят: «О, это не изменится - оно в камне!» и все же, через некоторое время они возвращаются и говорят: «Нам нужны эти изменения, и они нужны нам сейчас!» и положи трубку, прежде чем ты сможешь сказать им, что они сказали, что это никогда не изменится.

Есть ли какая-то особая причина, по которой они это сделали? Я знаю, что это предложение звучит как убийство или что-то в этом роде, но все же. Я удивлен только этим?

Answer 1

"true" и "false" определяются самим языком ; таким образом, в этом случае относительно безопасно жестко закодировать строковые значения.

JLS 4.2.5 Тип boolean и boolean Значения

... преобразует операнд boolean в String (либо "true", либо "false") ...

Точно так же язык определяет, например, null ссылки становятся "null" во время преобразования строки.

JLS 15.18.1.1 Преобразование строки

Если ссылка null, она преобразуется в строку "null" (четыре символа ASCII n, u, l, l)

Обычно лучше не жестко кодировать константы по всей базе кода, но когда язык гарантирует, какими должны быть константы, это становится меньшей проблемой.

---

Вот фрагмент из OpenJDK для 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;
}

Обратите внимание, что StringBuilder extends AbstractStringBuilder.

Answer 2

Они используют другой тип камня для типичных системных требований, чем они используют для спецификаций Java. Первые в основном написаны на мыльном камне, а последние выгравированы на корунде с помощью писца с алмазным наконечником.

Реально, существует нулевая вероятность того, что Boolean.toString() будет изменен, чтобы вернуть что-то отличное от "true" и "false". Это потенциально может сломать сотни тысяч Java-приложений. Sun / Oracle не будет делать что-то подобное. Это было бы катастрофично для их бизнес-модели Java.