JLS.17.5.4 Write Protected Fields

[ANONYMOUS.COWARD0xC0DE]

/* from java/lang/System.java */
public final static InputStream in = nullInputStream();
[...]
java.lang.System.nullInputStream(void) simply returns null.

From this I can not tell how the compiler would know to denote this as

a write protected field.
Do compilers simply hard code System.out,in,err as write protected
fields?

 

[Mike Schilling]

/* from java/lang/System.java */
public final static InputStream in = nullInputStream();
[...]
java.lang.System.nullInputStream(void) simply returns null.

From this I can not tell how the compiler would know to denote this
as

a write protected field.
Do compilers simply hard code System.out,in,err as write protected
fields?

Yes, they are unique. I recall that one of the papers describing the new
synchronization model for Java had to treat access to them specially, since
they're the only read-only but non-final fields in all of Java. Obviously,
they should be accessed via getters, but there's no way to make that change
without breaking compatibility. [1]

1. OK, it's possible, but it's a lot of trouble.

 

[Thomas Hawtin]

/* from java/lang/System.java */
public final static InputStream in = nullInputStream();
[...]
java.lang.System.nullInputStream(void) simply returns null.

From this I can not tell how the compiler would know to denote this as

a write protected field.
Do compilers simply hard code System.out,in,err as write protected
fields?

It's the JVM which treats them specially.

Back in JDK 1.0 these fields were non-final. That is a security flaw.

1.1 made these fields final. It also added setIn/setErr/setOut. The
obvious implementation would be to have proxy streams on in/err/out.
However, what they actually do is change the final variables (through
native code).

1.5 gives the JVM some extra optimisation freedom for final variables
(presumably JVM were actually using some of this before it was legal).
To make in/err/out work correctly, the specification has to make special
cases for these three variables only.

Tom Hawtin