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;
Hi,
JSR 310 is developing a new date and time API expected to be included in
the JDK.
We would appreciate your input to help refine the method naming
alternatives.
Please a take few minutes to give your input.
http://www.rationalsurvey.com/s/3775
Thanks, Roger
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.
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
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: T
Changeset: df3152beef2f
Author:xuelei
Date: 2012-05-14 07:26 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/df3152beef2f
7167988: PKIX CertPathBuilder in reverse mode doesn't work if more than one
trust anchor is specified
Reviewed-by: mullan
! src/share/classes/sun/securit
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 ch
