On 15/05/2012 2:41 AM, 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.
I do not agree.
The above can only print zero if program-order is violated, which I
don't believe it can or should be.
But the "set of writes" is the same regardless of whether default or
explicit initialization is used. The JMM explicitly states (17.4.4) that
the write of the default value synchronizes with the first action in
every thread and acts as-if each object were allocated and initialized
to default values when the VM starts.
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.
Initializing to a default value should be a no-op. I had thought javac
already optimized these away but perhaps it is only the JIT.
David
-----
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
