so I think I'm missing something. I am aware that
If no constructor is supplied java makes one for you.
If there's a constructor defined, default constructor by java is not used.
Constructor is used to initialize variables
Here's some simple code:
class a {
int f; // a variable with no value
int c; // a variable later initialized by the constructor
int b = 5; // this will be second question, a less important one
a(){
c = 1; // Constructor initiatives C, but not F
}
public static void main(String[] args){
a var = new a();
System.out.print(var.f); // Please see my comment below
}
}
Here's what I do not understand. Why is var.f printed? I did not initialize f in the constructor, however, there's no compile error and 0 value is initialed. I don't understand how '0' is initialized to 'f' despite me not having used it in constructor
Regarding b = 5, I understand what this code leads to, however, I do not think I understand what/who does the initialization here, is it new operator or something else? Thanks.
Edit: since the answers so far are not addressing my question
I am aware of the default values. I thought it was the default constructor that assigned them, is it not? If not, what assigns default values?
Java like most of programming languages has default values for uninitialized variables. Every numeric type of variable is initialized to 0-related value.
Boolean is false as default.
Strings and all of the objects have null as their default value.
Check docs for more info: https://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html
int is a primitive data type. By definition, primitives cannot be null as they are not objects and will have a default value if not initialized. See here: https://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html
If you want to be able to have a variable that is not initialized, you can use the object equivalent of an int java.lang.Integer
Instance variables that are declared but not initialised are given a default value.
References take a default value of null.
Primitives take a default value of zero
In regards to your query on your primitive int variable b, the new operator is not required, the new operator is used when instantiating a reference. When an instantiating a reference an object is created and memory is allocated on the JVM for that object.
Strings are a reference variable, but may be instantiated using the new keyword for example:
String example = new String("abc");
System.out.println(example); // prints abc.
Usually you would just write:
String example = "abc";
In the latter the literal is placed in to the 'string pool'...
You can read more about the string pool here: http://examples.javacodegeeks.com/core-java/lang/string/java-string-pool-example/
If no constructor is supplied java makes one for you.
Correct.
If there's a constructor defined, default constructor by java is not used.
It is not generated.
Constructor is used to initialize variables
Correct.
c = 1; // Constructor initiatives C, but not F
Untrue. Your code initializes c. The generated constructor initializes both.
I did not initialize f in the constructor
No, but Java did.
Java generates the following code for a constructor:
A super call.
Default initialization code for all variables declared without initializers. The default values are false, zero, or null as appropriate to the type.
Calls to all anonymous initializer blocks. (2) and (3) happen in textual order and can therefore be interleaved with each other.
Regarding b = 5, I understand what this code leads to, however, I do not think I understand what/who does the initialization here, is it new operator or something else?
See above.
I am aware of the default values. I thought it was the default constructor that assigned them, is it not?
No.
If not, what assigns default values?
The constructor. Any constructor.
Related
In Java, what is the difference and best way to do?
Integer x = null; // x later assign some value.
Integer y; // y later initialize and use it.
The answer depends on what type of variable are you referring.
For class variables, there's no difference, see the JLS - 4.12.5. Initial Values of Variables:
... Every variable in a program must have a value before its value is
used:
For all reference types (§4.3), the default value is null.
Meaning, there is no difference, the later is implicitly set to null.
If the variables are local, they must be assigned before you pass them to a method:
myMethod(x); //will compile :)
myMethod(y) //won't compile :(
Local variables must be assigned to something before they are used.
Integer x = null;
myFunction(x);
// myFunction is called with the argument null
Integer y;
myFunction(y);
// This will not compile because the variable has not been initialised
Class variables are always initialised to a default value (null for object types, something like zero for primitives) if you don't explicitly initialise them. Local variables are not implicitly initialised.
Its better to not set it to null, otherwise you can by accident use it and cause NPE. Compiler wont help you with compile error. Only set to null if you want to have logic like if ( x != null ) { /use it/ }
No difference at all. Both cases when ever you want to use it, local variable must be in initialized form(must have a value).
From Java doc
Similar to how an object stores its state in fields, a method will
often store its temporary state in local variables. The syntax for
declaring a local variable is similar to declaring a field (for
example, int count = 0;). There is no special keyword designating a
variable as local; that determination comes entirely from the location
in which the variable is declared — which is between the opening and
closing braces of a method. As such, local variables are only visible
to the methods in which they are declared; they are not accessible
from the rest of the class.
Internally there is no difference. Also it is a debatable topic.
Use the local variable only if it is really required. Local variables are mostly in the following scenarios (I may be missing few other).
As a shorthand or for Readability
Integer myObject = someObject.someFunction().someOtherFunction();
If we use the syntax like that in many places, code will become clumsy.
For accessibility
Object returnObject = null;
if(mycondition)
{
returnObject = value1;
}
else if(secondCondition)
{
returnObject = value2;
}
return returnObject;
The caller of the above code snippet will take decision based on the return value.
Honestly speaking i am not seeing other valid use case to declare a variable without initial value.
Conclusion (Best Practice):
Declare local variable only if required
Always create local variable with default value.
No differences at all expect for one thing, if you don't initialize it and later on you try to use this variable (without changing the reference) means an error at compilation time, but if you initialize it and you use it later on (without changing the reference) means a NullPointerException.
I show you with an example.
Without initializing
Integer y;
y.intValue(); // Compilation error
With initializing
Integer x = null;
x.intValue(); // You are able to compile it but NullPointerException
we know that...
Instance Variable are initialized in default constructor. For eg.
public class H{
int x;
public static void main(String... args){
System.out.print(new H().x);
}
}
The O/P of above code is 0 because there is a default constructor which is called , and that constructor initialized the x to 0.
Now, my question is, if we run the below code, i.e.
public class H{
int x;
public H(){}
public static void main(String... args){
System.out.print(new H().x);
}
}
The actual O/P is 0 in this case also, but I think there should be compiler error that x is not initialized, because we have override the default constructor and didn't initialize x.I think I have made my question clear..
In Java, instance members are defaulted to the all-bits-off version of their value automatically (ints are 0, object references are null, floats are 0.0, booleans are false, and so on). It's not something the default constructor does, it's done before the constructor runs.
The order is:
Default the instance members to their all-bits-off value. (The optimizer can skip this if it sees #2 below or possibly if it can prove to itself that nothing uses the member prior to an initialization per #3 below.)
Apply any inline initialization of them. For instance:
int a = 42;
Apply instance initialization blocks in source code order.
Call the appropriate constructor.
So for example:
class Example {
int a = 42;
// Instance initializer block:
{
this.a = 67;
}
Example() {
System.out.println(this.a);
}
}
new Example() outputs 67.
Obviously, initializing in both places like that would be poor practice, this is just for illustration.
Non-final fields are initialized by default in java. Only variables inside methods and final fields are not initialized by default.
If you had declared x to be final, then you would be correct. You would have a compile error in the code.
All instance level variables are initialized to their default values irrespective of whether the constructor has been overloaded ( or explicit no-argument constructor has been added). The constructor merely changes the default value(s).
Instance variables have default values associated with them
From The Java™ Tutorials:
Default values
It's not always necessary to assign a value when a field is declared. Fields that are declared but not initialized will be set to a reasonable default by the compiler. Generally speaking, this default will be zero or null, depending on the data type.
Java is quite neat to programmers (unlike others, C for instance), this means that it initializes fields automatically. An exception is final fields and fields inside a methods (where the compiler will then produce an error).
Hope it helped.
Why aren't default values assigned to the variables, that haven't been initialized within a Class with main function???
class Test {
public static void main(String[] args) {
int x;// x has no default value
String y;// y has no default value
System.out.println("x is " + );
System.out.println("y is " + );
}
}
Whereas the default values get assigned in case the variables remain uninitialized in a class without any main function.
class Student {
String name; // name has default value null
int age; // age has default value 0
boolean isScienceMajor; // isScienceMajor has default value false
char gender; // c has default value '\u0000'
int x;
String y;
}
Be aware that the code in the question represents different situations. In the first case, the variables are local and exist inside the main() method. In the second case you're declaring instance attributes, not local variables.
In Java, only the attributes are initialized automatically with default values. In all the methods, even in the main() method, you must explicitly provide an initialization value for the variables declared locally inside the method.
This is explained in the Java Language Specification, section §4.12.5:
Each class variable, instance variable, or array component is initialized with a default value when it is created (§15.9, §15.10)
Each method parameter (§8.4.1) is initialized to the corresponding argument value provided by the invoker of the method (§15.12)
Each constructor parameter (§8.8.1) is initialized to the corresponding argument value provided by a class instance creation expression (§15.9) or explicit constructor invocation (§8.8.7)
An exception parameter (§14.20) is initialized to the thrown object representing the exception (§11.3, §14.18)
A local variable (§14.4, §14.14) must be explicitly given a value before it is used, by either initialization (§14.4) or assignment (§15.26), in a way that can be verified using the rules for definite assignment (§16)
To see several reasons why local variables are not initialized automatically, please take a look at this previous question.
The basic reason is that, in order to catch a common programmer error, the Java authors decided to ensure that every variable is assigned before it is used. However, it is not possible to enforce this for fields, so they had to spec default values for fields.
You do get an error if you use a field in a constructor before it is initialized, but there is no way for the compiler to prevent this:
class C {
int f;
C() {
init();
}
void init() {
System.out.println(f);
}
}
When the JVM is creating the new object instance, it has to allocate memory for the attributes because they are part of the class itself. The mere existence of a Java primitive int requires 4 bytes of memory to be allocated, whereas an Integer can be set to null since it's an object. That's why classes must have their attributes set to something upon being initialized.
Reading the value of a variable before it has been given a value is a common source of bugs. Forcing you to assign a value before using a variable makes programs safer: you'll know you'll get the value you expect and not some default value just because you didn't anticipate a certain program flow.
Unfortunately the liveness analysis that implementing this needs can only be done for local variables, and you can access instance fields before the program has initialized them with a value. To avoid unpredictable behavior the JVM initializes instance fields to default values.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Should I initialize variable within constructor or outside constructor
For example I have a field int x.
Does Java prefer the field to be initialized when it's declared
int x = 0;
or rather in the constructor?
public foo() {
x = 0;
}
Which is more preferred from a designing perspective?
Both are good, as long as you know what will happen.
The order in which they will be initialized is this:
Class members (like: public int x = 0;)
Constructors (like: this.x = 0;)
However, initializing integers to zero is a no-op. Java does this automatically.
A little demo to demonstrate an error of ignoring the order of initialization:
class Foo
{
public String str;
public String strTwo = "Here is str: " + str;
public Foo()
{
str = "Java";
System.out.println(strTwo);
}
}
This will print Here is str: null.
Instance variables of primitive types are initialized implicitly whereas reference variable are assigned with null values.
So if you want to assign like ::
int x=0;
it will be x=0 for all objects.
But in case of constructors you can initialize them with different value in different constructor, though its not a good practice to initialize with different values in different constructor.
Does Java prefer the field to be initialized when it's declared or rather in the constructor?
If you are initializing with default value, it'll be redundant to initialize either in constructor or at declaration time.
However, if you want to initialize with a value different from default value, constructor should be used over delaration.
Which is more preferred from a designing perspective?
From design point of view, No difference at all. It is implementaiton detail.
My preference is to initialize default values outside constructor like
int x=0;
So that if you have multiple constructors and lot of instance variables, you won't forgot to initialize. In-case if I require specific value to variable, then I will re-initialize in constructor.
From what I recall, the bytecode produced by the compiler in both instances is pretty much identical, and it is really just a matter of preference and coding style. Personally, I tend to prefer to initialize variables in the constructor - In some cases you will have to initialize variables in a constructor anyway (Such as when passing in arguments to a constructor), and it means you need only look in one place to understand what is going on, rather than 2.
(On a side note - in your example there is no need to do "int x = 0" since defining "int x;" will automatically have it set to 0.)
public foo() {
x = 0;
}
this will be good. if u use this int x =0 it will be for all objects. but the constructor notation is for objects which are created by that particular constructors.
Consider this:
public class TestClass {
private String a;
private String b;
public TestClass()
{
a = "initialized";
}
public void doSomething()
{
String c;
a.notify(); // This is fine
b.notify(); // This is fine - but will end in an exception
c.notify(); // "Local variable c may not have been initialised"
}
}
I don't get it. "b" is never initialized but will give the same run-time error as "c", which is a compile-time error. Why the difference between local variables and members?
Edit: making the members private was my initial intention, and the question still stands...
The language defines it this way.
Instance variables of object type default to being initialized to null.
Local variables of object type are not initialized by default and it's a compile time error to access an undefined variable.
See section 4.12.5 for SE7 (same section still as of SE14)
http://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.12.5
Here's the deal. When you call
TestClass tc = new TestClass();
the new command performs four important tasks:
Allocates memory on the heap for the new object.
Initiates the class fields to their default values (numerics to 0, boolean to false, objects to null).
Calls the constructor (which may re-initiate the fields, or may not).
Returns a reference to the new object.
So your fields 'a' and 'b' are both initiated to null, and 'a' is re-initiated in the constructor. This process is not relevant for method calling, so local variable 'c' is never initialized.
For the gravely insomniac, read this.
The rules for definite assignment are quite difficult (read chapter 16 of JLS 3rd Ed). It's not practical to enforce definite assignment on fields. As it stands, it's even possible to observe final fields before they are initialised.
The compiler can figure out that c will never be set. The b variable could be set by someone else after the constructor is called, but before doSomething(). Make b private and the compiler may be able to help.
The compiler can tell from the code for doSomething() that c is declared there and never initialized. Because it is local, there is no possibility that it is initialized elsewhere.
It can't tell when or where you are going to call doSomething(). b is a public member. It is entirely possible that you would initialize it in other code before calling the method.
Member-variables are initialized to null or to their default primitive values, if they are primitives.
Local variables are UNDEFINED and are not initialized and you are responsible for setting the initial value. The compiler prevents you from using them.
Therefore, b is initialized when the class TestClass is instantiated while c is undefined.
Note: null is different from undefined.
You've actually identified one of the bigger holes in Java's system of generally attempting to find errors at edit/compile time rather than run time because--as the accepted answer said--it's difficult to tell if b is initialized or not.
There are a few patterns to work around this flaw. First is "Final by default". If your members were final, you would have to fill them in with the constructor--and it would use path-analysis to ensure that every possible path fills in the finals (You could still assign it "Null" which would defeat the purpose but at least you would be forced to recognize that you were doing it intentionally).
A second approach is strict null checking. You can turn it on in eclipse settings either by project or in default properties. I believe it would force you to null-check your b.notify() before you call it. This can quickly get out of hand so it tends to go with a set of annotations to make things simpler:
The annotations might have different names but in concept once you turn on strict null checking and the annotations the types of variables are "nullable" and "NotNull". If you try to place a Nullable into a not-null variable you must check it for null first. Parameters and return types are also annotated so you don't have to check for null every single time you assign to a not-null variable.
There is also a "NotNullByDefault" package level annotation that will make the editor assume that no variable can ever have a null value unless you tag it Nullable.
These annotations mostly apply at the editor level--You can turn them on within eclipse and probably other editors--which is why they aren't necessarily standardized. (At least last time I check, Java 8 might have some annotations I haven't found yet)