title: Protecting fields from Reflection - The strange case of the System.security
body: <p>I am currently looking into java security and came across a strange phenomenon. The SecurityManager in java is stored in the field "security" in java.lang.System. Interestingly, the field seems to be protected against reflective access, which does make sense, but as far as I know this field is the only one which is. So here is the example: </p>
  
  <pre><code>for(Field f : System.class.getDeclaredFields())
      System.out.println(f);
  </code></pre>
  
  <p>outputs </p>
  
  <pre><code>public static final java.io.InputStream java.lang.System.in
  public static final java.io.PrintStream java.lang.System.out
  public static final java.io.PrintStream java.lang.System.err
  private static volatile java.io.Console java.lang.System.cons
  private static java.util.Properties java.lang.System.props
  private static java.lang.String java.lang.System.lineSeparator
  </code></pre>
  
  <p>Interestingly: the field declared as </p>
  
  <pre><code>private static volatile SecurityManager security = null;
  </code></pre>
  
  <p>is not in the list, and sure enough a call to </p>
  
  <pre><code>System.class.getDeclaredField("security"); 
  </code></pre>
  
  <p>yields a NoSuchFieldException. As I couldn't find anything about this online, and I am pretty sure this field used to be accessible via reflection (see also, for example, this <a href="http://slightlyrandombrokenthoughts.blogspot.de/2010/02/java-se-security-part-iii-keys.html">blog post</a> from 2010 which describes accessing this field) I was wondering a) was this implemented as a quick fix to prevent easily disabling the securitymanager via reflection and b) how this is implemented (or rather is there any chance of protecting other private fields from reflection as well).</p>