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

Kurchi Hazra kurchi.subhra.hazra at oracle.com
Mon May 14 20:00:11 UTC 2012


Thanks for the detailed explanation.
I have removed the default initializations: 
http://cr.openjdk.java.net/~khazra/7164636/webrev.01/

- 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
>>>>

-- 
-Kurchi




More information about the core-libs-dev mailing list