5

I was wondering whether I should initialize class members in java with an initial value and then change that value to some other given value in the constructor, or should I avoid doing such a thing?

code example

public class Test {
    private int value = 5;

    public Test(int value) {
        this.value = value;
 }
}
pdobb
  • 17,688
  • 5
  • 59
  • 74
G. Sz.
  • 55
  • 1
  • 2
  • 4

5 Answers5

12

If not specified,:

primitive bytes, shorts, ints, longs, floats and doubles are initialized to 0

booleans are initialized to false

Objects are initialized to null

dkatzel
  • 31,188
  • 3
  • 63
  • 67
  • Not to mention primitives `float` and `double` which are initialized to `0.0` – flotothemoon Aug 21 '14 at 19:32
  • 1
    Please update it correctly ;) byte, short, int ànd long are initalized to 0. float and double are initialized to 0.0 (there is a difference between 0 and 0.0 (for floating point types at least)). char is also a primitive and its initial value is `\u0000`. – flotothemoon Aug 21 '14 at 21:07
4

If we are talking about class fields than all unset variables of

  • primitive types are set to
    • 0 (numeric ones like int, long, double...)
    • \u0000 (char)
    • false (boolean).
  • object types like String, Integer, or AnyOtherClass are set to null

so actually it doesn't matter if you set it explicitly, because

private int x;    
private Integer y;

is equivalent of 

private int x = 0;    
private Integer y = null;
Pshemo
  • 122,468
  • 25
  • 185
  • 269
1

Java give value class variables, I mean they are initialized by JVM and you can use them. But you must to search their default values to use them correctly.

On the other hand, JVM does not initialize the local variables which is created in methods. So if you create any variable on methods you have to assign them to a value before use them.

PeerNet
  • 855
  • 1
  • 16
  • 31
  • 2
    Welcome on SO! In your answer, you refer to another answer. Note that "above" and "below" may change at any time, thus you should comment on an answer if you wish to add something to it instead of posting a new answer with your additions. To comment on an answer you need to have gained some reputation first, though. – dst Aug 21 '14 at 21:09
0

A not initialized int is always 0 on heap. It can't never be null. Mind: within a method it must be initialized, not only declared.

atmin
  • 370
  • 1
  • 7
0

First, you cannot initialize an int value with null. The default value of an int is zero, but initializing it in both the field declaration and the constructor is pointless. Assuming the compiler does not omit the field initializer completely, it effectively compiles to this:

public class Test {
    private int value;

    public Test(int value) {
        this.value = /* field initializer value */;
        this.value = value;
    }
}

Unless you want to initialize a field with a non-default value (non-zero, non-null), there is generally no reason to add an initializer. This is especially true if the initializer is redundant, as is the case above. The default value for a field is the "zeroed out" value of the field type, e.g., 0 for numeric types, false for a boolean, and null for objects. Note that there is an exception with respect to fields: final fields must have an initializer if they are not assigned exactly once in every constructor; final fields have no implicit default value.

Now, it may be necessary to initialize method variables to guarantee they have a value by the time they are read, as variables do not have a default/implied initializer as fields do. Whether an explicit initializer is necessary depends on the control flow of your method.

Mike Strobel
  • 25,075
  • 57
  • 69
  • Some teams enforce initializing objects to null to quiet the IDE complaining 'xyz variable might not have been initialized', so its a good practice to initialize them to null in those cases. – Jonathan Cole Feb 22 '22 at 23:02
  • @JonathanCole I'd say that's a _bad_ practice, unless `null` is _specifically the expected, valid value_ in those cases. Otherwise, if the IDE says the variable might not be initialized, then there is likely a code path where it _doesn't_ get initialized, and you should fix _that_ problem. – Mike Strobel Feb 23 '22 at 17:09
  • Way old but just saw @Mike Strobel, response and I agree Mike, I was indicating its good practice when team standard requires it. Also in this case the path is almost always within method scope, and the null checks are needed (so null is the 'expected' value in your statement). I agree some teams have 'bad practices' and sometimes consistancy must win the day (from the team's perspective), otherwise we should employ defaults or value objects as Mike suggests. – Jonathan Cole May 23 '22 at 17:39