java: “остаточний” System.out, System.in та System.err?

System.outоголошується як public static final PrintStream out.

Але ви можете зателефонувати, System.setOut()щоб перепризначити його.

А? Як це можливо, якщо це final?

(те саме стосується System.inі System.err)

І що ще важливіше, якщо ви можете мутувати загальнодоступні статичні кінцеві поля, що це означає щодо гарантій (якщо такі є), які finalвам дають? (Я ніколи не усвідомлював і не очікував, що System.in/out/err поводився як finalзмінна)

JLS 17.5.4 Запис захищених полів :

Зазвичай остаточні статичні поля не можуть бути змінені. Однак System.in, System.outі System.errє остаточними статичними полями, яким із застарілих причин потрібно дозволити змінювати методи System.setIn, System.setOutта System.setErr. Ми називаємо ці поля захищеними від запису, щоб відрізнити їх від звичайних кінцевих полів.

Компілятор повинен поводитися з цими полями інакше, ніж з іншими кінцевими полями. Наприклад, зчитування звичайного кінцевого поля є "імунітетом" до синхронізації: бар'єр, який бере участь у блокуванні або мінливому зчитуванні, не повинен впливати на те, яке значення зчитується з кінцевого поля. Оскільки значення захищених від запису полів може змінюватися, події синхронізації повинні впливати на них. Отже, семантика диктує, що ці поля повинні розглядатися як звичайні поля, які не можна змінити за допомогою коду користувача, якщо тільки цей код користувача не знаходиться в Systemкласі.

До речі, насправді ви можете мутувати finalполя за допомогою відображення, викликаючи setAccessible(true)їх (або використовуючи Unsafeметоди). Такі методи використовуються під час десериалізації, Hibernate та іншими фреймворками тощо, але вони мають одне обмеження: код, який бачив значення остаточного поля до модифікації, не гарантовано бачить нове значення після модифікації. Особливість розглянутих полів полягає в тому, що вони позбавлені цього обмеження, оскільки компілятор обробляє їх особливим чином.

Java використовує власний метод для реалізації setIn(), setOut()і setErr().

На моєму JDK1.6.0_20 setOut()виглядає так:

public static void setOut(PrintStream out) {
    checkIO();
    setOut0(out);
}

...

private static native void setOut0(PrintStream out);

Ви все ще не можете "нормально" перепризначати finalзмінні, і навіть у цьому випадку ви не перепризначаєте поле безпосередньо (тобто ви все одно не можете скомпілювати " System.out = myOut"). Власні методи дозволяють деякі речі, які ви просто не можете зробити у звичайній Java, що пояснює, чому існують обмеження для власних методів, таких як вимога підпису аплету для використання власних бібліотек.

Щоб продовжити те, що сказав Адам, ось імпл:

public static void setOut(PrintStream out) {
    checkIO();
    setOut0(out);
}

і setOut0 визначається як:

private static native void setOut0(PrintStream out);

Залежить від реалізації. Останній може ніколи не змінитися, але це може бути проксі / адаптер / декоратор для фактичного потоку виводу, setOut може, наприклад, встановити член, до якого фактично пише вихідний член. На практиці, однак, це встановлено спочатку.

значення, outяке оголошено як остаточне у класі System, є змінною рівня класу. де як out, що в наведеному нижче методі, є локальною змінною. ми не де передаємо рівень класу, який насправді є остаточним, у цей метод

public static void setOut(PrintStream out) {
  checkIO();
  setOut0(out);
    }

використання вищевказаного методу наведено нижче:

System.setOut(new PrintStream(new FileOutputStream("somefile.txt")));

тепер дані будуть перенаправлені у файл. сподіваюся, це пояснення має сенс.

Тож ніякої ролі власних методів чи роздумів тут у зміні призначення кінцевого ключового слова.

Щодо того, як, ми можемо поглянути на вихідний код, щоб java/lang/System.c:

/*
 * The following three functions implement setter methods for
 * java.lang.System.{in, out, err}. They are natively implemented
 * because they violate the semantics of the language (i.e. set final
 * variable).
 */
JNIEXPORT void JNICALL
Java_java_lang_System_setOut0(JNIEnv *env, jclass cla, jobject stream)
{
    jfieldID fid =
        (*env)->GetStaticFieldID(env,cla,"out","Ljava/io/PrintStream;");
    if (fid == 0)
        return;
    (*env)->SetStaticObjectField(env,cla,fid,stream);
}

...

Іншими словами, JNI може "обдурити". ; )

Я думаю setout0, що змінює змінну місцевого рівня out, вона не може змінити змінну рівня класу out.