Which is proper/correct

[David McCallum]

Given two versions on the same class

public class Test {
private int i=0;
}

and

public class Test (
private int i;

Test() {
i=0;
}
}

Is there any difference in new Test() given that "i" is always initialised
to 0. Which is the correct way to implement this?

TIA

David McCallum

 

[Michael Borgwardt]

Given two versions on the same class

public class Test {
private int i=0;
}

and

public class Test (
private int i;

Test() {
i=0;
}
}

Is there any difference in new Test() given that "i" is always initialised
to 0.

The two statements are not executed at the same time in the initialization
process, but this should not matter unless you do really weird stuff in the
constructor.

Which is the correct way to implement this?

There's no "correct" way. Both are perfectly valid, and if fact neither is necessary,
since int class fields are initialized to 0 anyway; you don't have to do it
explicitly.

Do what seems more clear to you.

 

[Chris]

Either approach is fine if you have just one constructor.

If however you have more than one, I would initialise the field in the
class declaration rather than the constructor:

class Thing
{
private int field = 42;

// default ctor
public Thing()
{
...
}

// other ctors
public Thing( ... ) { ... }
}

This means that the value is initialised correctly for all
constructors, reducing the chances of a ****-up.

- sarge

 

[BarryNL]

The two statements are not executed at the same time in the initialization
process,...

In fact, they are. The direct assignment is actually moved into the
constructor during the compile process. The reason being that otherwise
the code would execute before the constructor of any superclass. For
example, consider:

public class X {


public static void main(String[] args) throws Exception {
new Class2();
}


public static abstract class Class1 {
public Class1() {
System.out.println("Value(c1)=" + getValue());
}


public abstract int getValue();
}


public static class Class2 extends Class1 {
private int val = 42;


public Class2() {
System.out.println("Value(c2)=" + getValue());
}


public int getValue() {
return val;
}
}
}

The output of this is:

Value(c1)=0
Value(c2)=42

So, you can see that the assignment to val in Class2 has not taken place
before the automatic call to the superclass constructor.

 

[Frank Birbacher]

Hi!

The output of this is:

Value(c1)=0
Value(c2)=42

So, you can see that the assignment to val in Class2 has not taken place
before the automatic call to the superclass constructor.

Uh! Why are you allowed to call non-static methods of not-constructed
objects?

Frank

 

[BarryNL]

Hi!



Uh! Why are you allowed to call non-static methods of not-constructed
objects?

I can't think of a good reason for this. Personally I think this is a
major 'gotcha' - it's best just to be aware of it and make sure you
never do it.

 

[Emir]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Either approach is fine if you have just one constructor.

If however you have more than one, I would initialise the field in the
class declaration rather than the constructor:

class Thing
{
private int field = 42;

// default ctor
public Thing()
{
...
}

// other ctors
public Thing( ... ) { ... }
}

This means that the value is initialised correctly for all
constructors, reducing the chances of a ****-up.

Someone already explained why initialization on declaration is deceptive and
thus a bad practice.

Whenever possible (because there may be *special* cases where this is not
possible or desireable), use initialization in the *default* constructor. For
classes with multiple constructors, use chaining:

public class LifeUniverseAndEverythingElse
{
private int m_answer;

public LifeUniverseAndEverythingElse()
{
m_answer = 42;
}

public LifeUniverseAndEverythingElse(String p_greeting)
{
this();
System.out.println(p_greeting + ", Arthur!");
}

public LifeUniverseAndEverythingElse(Object p_something)
{
this();
System.out.println("Talking doors are made of [" +
p_something.getClass().getName() + "]");
}
}
- --
Emir.

"Politicians, like diapers, have to be changed frequently.
And for the very same reason." -- Anonymous
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)

iD8DBQFACBISuSy542G+Z7QRAnr0AJ9SRIJzDd84tlL7H0ytCV6Yp6e9AQCgkpej
4upvaj0HoiG3WsKqugMlfjw=
=CKjy
-----END PGP SIGNATURE-----