Home/ Questions/Q 9018951
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-16T04:39:37+00:00

Using reflection and also from the src.zip available in the installed JDK by the

  • 0

Using reflection and also from the src.zip available in the installed JDK by the installer purveyed by http://docs.oracle.com, I found the following fields of java.lang.System,

in, out & err are declared as final, but they have respective (public) setter methods which in turn invoke their respective native couter-part.

For example, I could successfully re-direct console output to a file.

We can set final variables exactly once we have initialized it in the Java code.

My question is : is this rule of final not applicable to the native code?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    My question is : is this rule of final not applicable to the native code?

    Native code can break the rules on final. It can also break the access rules and basic type safety, and various other things.

    The point about final fields not actually being immutable is actually recognized in the JLS: see JLS 17.5.3. The gist of this is that if you do change a final (via reflection for example), certain guarantees no longer hold. And changing the value of a final that represents a compile time constant is liable to have no effect at all.

    But as @ignis points out, System.in/out/err get special mention in the JLS as being “write-protected” (JLS 17.5.4) rather than having the normal final semantics. Basically, this means that the final guarantees do hold even if the variables are changed.

    why have the variables to be final when there will be a setter anyways?

    In this particular case it is 1) to prevent System.in/out/err from being clobbered by an accidental assignment, and 2) so that changes can be controlled by the SecurityManager.

    • 0