Code Review Request: 7164636: (prefs) Cleanup src/macosx/classes/java/util/prefs

[Brian Goetz]

 From a concurrency perspective it is also preferable to NOT initialize 
variables to their default values, as doing so can cause some weird 
problems.  For example:

class A {
     public int x = 0;

     public void increment() { ++x; }
     public int get() { return x; }
}

// Thread X
// Assume: Thread X never touches 'a' again
A a = new A();

// Thread Y
// Assume: No other thread than Y touches 'a'
if (a != null) {
     a.increment();
     System.out.println(a.get());
}

With the explicit initialization, this code could print zero (because 
the set of writes to 'x' contains two writes, one by X to zero and one 
by Y to 1), whereas without the explicit initialization, it would always 
print one.

Now, this is an example of "improper publication" of the A by Thread X, 
but this is the sort of improper publication (where an object was 
initialized by one thread and then "handed off" to another) that was 
widely thought to be safe a long time ago and was enshrined in many 
examples, particularly Swing examples.

The sharing here is clearly wrong, but the approach of not unnecessarily 
initializing non-final fields eliminates a path to tickling the improper 
publication into actually producing the wrong result.

On 5/14/2012 5:28 AM, Chris Hegarty wrote:
> This change looks fine to me.
>
> Trivially, changedFiles and cachedFiles do not need to be set to null (I
> believe this will generate a little less bytecode), as this is the
> default reference value. Since you are in clean-up mode ;-)
>
> -Chris.
>
> On 11/05/2012 22:46, Kurchi Hazra wrote:
>> Hi,
>>
>> This change aims at removing some rawtype usages in
>> src/macosx/classes/java/util/prefs that were brought
>> into jdk8 with the macport. I have added @Override tags too where
>> applicable.
>>
>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7164636
>> Webrev: http://cr.openjdk.java.net/~khazra/7164636/webrev.00/
>>
>>
>> Thanks,
>> Kurchi
>>