Nullness checker and built-in system properties

Some Java system properties are built in; see 
  http://java.sun.com/javase/6/docs/api/java/lang/System.html#getProperties%28%29
For example, System.getProperty("line.separator") will never return null.

If the Nullness Checker recognized this, then users could avoid writing
warning suppressions for those cases.

A user can override the built-in values by doing something perverse like
   System.setProperty("line.separator", null);
Therefore, the checker should also forbid the following:
 * calling System.setProperties
 * calling System.setProperty or Properties.setProperty with:
    * a nullable value, and
    * argument a non-literal, or a literal that is any of the given strings
 * treating a Properties as a Hashtable.  This includes assigning to a
   variable of type Hashtable or calling any method that is inherited from
   Hashtable.  (It would probably be possible to slightly relax this
   condition, but it would be safe.)
With these conditions, if the whole program has been checked with the
Nullness Checker, then I believe the checking is still sound.

Original issue reported on code.google.com by michael.ernst@gmail.com on 12 Jul 2010 at 4:25

Start at the Nullness Checker entry points for System.getProperty, System.setProperty, System.setProperties, and Properties.setProperty. Read the Java System and Properties API contract cited in the issue, then determine how built-in properties and Hashtable use should be represented. Done means sound nullness results without suppressions and rejection of the listed unsafe operations, with checker tests covering them.