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
