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

[Chris Hegarty]

On 14/05/12 21:00, Kurchi Hazra wrote:
> Thanks for the detailed explanation.
> I have removed the default initializations:
> http://cr.openjdk.java.net/~khazra/7164636/webrev.01/

This looks fine to me.

-Chris.

>
> - Kurchi
>
> On 5/14/2012 10:07 AM, Chris Hegarty wrote:
>> I always thought that removing these superfluous "default" values
>> would be a good clean up opportunity.
>>
>> Maybe one to be added to the warnings/StringBuilder potential cleanup
>> targets for external folks?
>>
>> -Chris.
>>
>> On 14/05/12 17:41, Brian Goetz wrote:
>>> 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
>>>>>
>