JLS.17.5.4 Write Protected Fields

Thread view:

ANONYMOUS.COWARD0xC0DE@gmail.com - 11 Aug 2007 04:09 GMT

/* 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?

Reply to this Message

Mike Schilling - 11 Aug 2007 07:10 GMT

> /* from java/lang/System.java */
> public final static InputStream in = nullInputStream();
[quoted text clipped - 6 lines]
> 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.

Reply to this Message

Thomas Hawtin - 11 Aug 2007 14:03 GMT

> /* from java/lang/System.java */
> public final static InputStream in = nullInputStream();
[quoted text clipped - 5 lines]
> 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

Reply to this Message

JLS.17.5.4 Write Protected Fields

Free Magazines