Code Review Request: 7164636: (prefs) Cleanup src/macosx/classes/java/util/prefs (original) (raw)
Chris Hegarty chris.hegarty at oracle.com
Tue May 15 18:00:24 UTC 2012
- Previous message: Code Review Request: 7164636: (prefs) Cleanup src/macosx/classes/java/util/prefs
- Next message: Code Review Request: 7164636: (prefs) Cleanup src/macosx/classes/java/util/prefs
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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/viewbug.do?bugid=7164636 Webrev: http://cr.openjdk.java.net/~khazra/7164636/webrev.00/
Thanks, Kurchi
- Previous message: Code Review Request: 7164636: (prefs) Cleanup src/macosx/classes/java/util/prefs
- Next message: Code Review Request: 7164636: (prefs) Cleanup src/macosx/classes/java/util/prefs
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]