This question already has answers here:
Default constructor vs. inline field initialization
(5 answers)
Closed 9 years ago.
I'm used to C++, where you have to instantiate everything in the constructer, but a recent realization has made me very confused about java. I was just instantiating things in the constructer, and then I realized this syntax was valid:
public class DebateCompetition {
private boolean isAdvanced;
ArrayList<Debate> debates = new ArrayList<Debate>(); //<------
ArrayList<Team> teams;
ArrayList<School> schools;
public void addSchool(School s) {
schools.add(s);
}
}
But that leaves a lot of questions. First: What does it do? Second: When is new ArrayList<Debate>() called? Third: Is this a best practice, or not?
First: What does it do?
All field initializers are executed (in order) before the code in the constructor is executed. (In this case you haven't declared a constructor, so there is a default no-args constructor which invokes the superclasses no-args constructor.)
Second: When is new ArrayList() called?
It is called during the instantiation of a new object.
The call happens after the superclass constructor has completed, and before executing the statements in this classes constructor. (In this case there are no statements in the constructor.)
Third: Is this a best practice, or not?
It is fine.
It's the equivalent of innitializing these variables at the beginning of a constructor. If, in addition, you are using an instance initialization block, they are initialized before the initialization block is invoked. After executing the superclass constructor the order is: fields initialized in the class body, initialization blocks, the constructor body. If you only declare fields in the class body, the compiler automatically initializes them anyway, to their default values: null for Object, false for boolean etc.
Related
I was learning about using this() to call an overloaded constructor and came across this restriction:
You can not use any instance variable of the constructor's class in a call
to this()
For example:
class Test{
int x;
public Test() {
this(x); //Does not compile
}
public Test(int y) {}
void method1() {
method2(x); //OK
}
void method2(int y) {}
}
I know that no need to pass an instance field to a constructor since it's visible by default. However, why is the same restriction not applied to instance methods?
There is one other requirement in Java: constructor calls (using this() must be performed first within any constructor. The constructors will initialize the object.
After that the instance fields are initialized after these initial calls. So as the field values are now well defined, you can use them for anything including calling other methods.
However, before the initial constructor calls, the fields are in an undefined state and cannot be used as argument for other constructor calls.
For these kind of things you need to look in the JLS:
If this constructor begins with an explicit constructor invocation (ยง8.8.7.1) of another constructor in the same class (using this), then evaluate the arguments and process that constructor invocation recursively using these same five steps. If that constructor invocation completes abruptly, then this procedure completes abruptly for the same reason; otherwise, continue with step 5.
Execute the instance initializers and instance variable initializers for this class, assigning the values of instance variable initializers to the corresponding instance variables, in the left-to-right order in which they appear textually in the source code for the class. If execution of any of these initializers results in an exception, then no further initializers are processed and this procedure completes abruptly with that same exception. Otherwise, continue with step 5.
So the instance variables are only initialized after the constructor calls. This makes sense, because it would be strange to first assign it the default value (zero or null) and then assign it another value from within a constructor.
The constructor constructs the instance. So we shouldn't expect the instance variable x to be initialized at the time the constructor starts.
On the other hand, an instance method can already access instance variables. There is no reason to forbid passing them as a parameter into another instance method.
However, when we start to think about it a bit further, that restriction on the constructor doesn't make that much sense anymore. We are able to access instance variables there as well, so why shouldn't we be able to pass it a parameter to another constructor?
So a better question to ask is: Why can't we pass an instance variable to call an overload of our constructor from within our constructor?
And this question has been beautifully answered. It could even be considered a duplicate (but since that pretext is neccessary to understand why, I wrote an answer instead of simply flagging).
The instance fields that are declared and initialized in the class body outside of the constructor, like your int x; are assigned after the call to the overloaded constructor.
You can compare that to the other restriction we have about calling constructor overloads: We can only do so in the first line of our constructor. Right at the start. And then, the variables are not yet initialized. But they are initialized right before the first non-constructor-call instruction.
Tangential information to why this other restriction is a thing can be found here and there:
Because the JLS says so. Could the JLS be changed in a compatible manner to allow it? Yup.
Historically, this() or super() must be first in a constructor. This
restriction was never popular, and perceived as arbitrary. There were
a number of subtle reasons, including the verification of
invokespecial, that contributed to this restriction. Over the years,
we've addressed these at the VM level, to the point where it becomes
practical to consider lifting this restriction, not just for records,
but for all constructors.
You should be educating the class order initialization f.e: https://www.baeldung.com/java-initialization
The int x field is not initialized when the class constructor is called. You can set (initialize) `int x 'in your constructor, but not call it.
I don't know why you have to follow this way, but you can use the static field:
class Test{
static int x;
public Test() {
this(x); //Does not compile
}
public Test(int y) {}
void method1() {
method2(x); //OK
}
void method2(int y) {}
}
You can also initialize a static field in the line where it is called,
static int x =4/2;
or in static block:
static int x;
static {
x = 4/2;
}
This question already has answers here:
Difference between Static methods and Instance methods
(10 answers)
Closed 4 years ago.
Whenever I have to call a method from another class, I first create an object and then call it through the object. But while I was writing some code, I mistakenly wrote classname.methodname(); and it worked.
I would usually write,
classname obj = new classname();
obj.methodname();
Here is the actual code:
Class 1
public class Dataset {
public static List<ECCardData> getDataset() {
//Code
}
in Class 2
List<ECCardData> dataset = Dataset.getDataset();
I noticed that the methodname() was static. Was that the reason?
Yes, for static methods (with suitable access modifier) you can call directly with your class by
YourClass.yourMethod();
and this way, too
YourClass anObject = new YourClass();
anObject.yourMethod();
Happy coding.
I hate answering my question, but I found the correct answer.
When a method is declare static, only one instance of that method will exist. When you create an object a new instance of the method is created, which is not possible for a static method. Therefore you use the class name.
classname.methodname(); //only one instance
classname obj;
obj.methodname(); //instance with obj as Object(IDE gives warning, should not be allowed, ideally)
The basic paradigm in Java is that you write classes, and that those
classes are instantiated. Instantiated objects (an instance of a
class) have attributes associated with them (member variables) that
affect their behavior; when the instance has its method executed it
will refer to these variables.
However, all objects of a particular type might have behavior that is
not dependent at all on member variables; these methods are best made
static. By being static, no instance of the class is required to run
the method.
You can do this to execute a static method:
classname.staticMethod();//Simply refers to the class's static code But
> to execute a non-static method, you must do this:
>
> classname obj = new classname();//Create an instance
> obj.nonstaticMethod();//Refer to the instance's class's code
This question already has answers here:
Why do we need a default no argument constructor in Java?
(7 answers)
Closed 5 years ago.
Why would anyone want to define a zero argument constructor when a default parameterless constructor is created during compile time anyway? Are there any benefits to doing so? are there any cases where it is better to define a zero argument constructor within a class for the sole purpose of preventing the default from being created during compile time?
Simple: you define it when you need it.
For example to call another constructor with some default values which are then used by the other constructor to initialize fields of the class.
When you write down an "empty" constructor that does nothing besides calling the super constructor then sure - you wrote useless code that should go away.
A default constructor is added by java internally if user does not define any parametrised constructor. It initialises any uninitialised fields to their default values.
Like int to 0
string to null
object to null
It's needed if you want to execute an init-function as soon as a new object of the class is created. For Example:
public class Example {
public Example() {
init();
}
public void init() {
//do some Stuff
}
}
But Just defining it without doing anything is not sensefull.
This question already has answers here:
What are the best practices for determining the tasks of Constructor, Initialization and Reset methods
(5 answers)
Closed 9 years ago.
In Java, but in other OO languages as well, is there a difference between initializing an attribute in its definition, as in
class Example {
public Sample sample_attribute = new Sample();
}
and using a constructor to initialize it?
class Example {
public Sample sample_attribute;
public Example() {
sample_attribute = new Sample();
}
}
I could not think of any practical difference, is there one? Otherwise, are there cases in which one method is better than the other, even if they have the same result?
The initialization order is matter here.
Set fields to default initial values (0, false, null)
Call the constructor for the object (but don't execute the body of
the constructor yet)
Invoke the constructor of the superclass
Initialize fields using initializers and initialization blocks
Execute the body of the constructor
So, first case will be initialize the variable sample_attribute in 4th step, second will initialize the variable sample_attribute in 5th step. It's all depends on your requirement.
If you want to access any of the variables from Constructor, you need to use 1st case.
When you initialize your fields with information which gets passed into the constructor, you have no other choice but to initialize in the constructor. Otherwise, I prefer initialization on the spot as it saves me lines of code I have to read later.
These two versions are equivalent. But if new Sample() threw a checked exception you wouldn't be able to initialize it at field declaration
This question already has answers here:
Initialize class fields in constructor or at declaration?
(16 answers)
Closed 10 years ago.
What is the difference between the following two, and which is more preferable??
public class foo {
int i = 2;
}
public class foo {
int i;
foo() {
i = 2;
}
}
In your example, there is no difference in behavioural semantics. In Java, all instance field initializers (and instance blocks) are executed after superclass initialization, and before the body of the constructor; see JLS 12.5.
The difference lies in code readability and (in other examples) avoiding repetitious coding and fragility1. These need to be assessed on a case-by-case basis.
It is also worth noting that there are some cases where you have to initialize in the constructor; i.e. when the initialization depends on a constructor parameter.
1 - The repetitiousness and fragility issues are flip-sides of the same thing. If you have multiple constructors, the "initialize in constructor" approach tends to lead to repetition. And if you add extra fields, you might to add the initialization to all relevant constructors; i.e. fragility.
If you have two or more constructors and intialization value differs in each of them, then you should use constructor initialization as there is no way to do the same with member initialization...
however if you have just one constructor...you can use member initialization for better code clarity..
In particular this case there is no difference in these two variants. First variant is more preferable, because initializations of fields inside constructor, as usual, use external values from constructor arguments.
First of all I think the second example should look like this:
public class foo{
int i;
foo(){
i = 0;
}
}
Otherwise i is just a local variable in the C'tor scope.
Second, the first example shows initialization which is called before the class C'tor is invoked. this is good if you want this to happen no matter what C'tor is used.
It also enables you to declare i as readonly.
In your first example, i is an instance variable of class foo (better name would be Foo). It's initialised at class loading.
In your second example, i is also an instance varaible but in this case initialised in the foo() constructor.
There is no real difference here, and especially with primitives.
However, in a multi-threaded environment, if you do intend to initialise your ivars in your constructor, and those ivars are non-primitive, you need to avoid the risk of exposing a partially constructed object. The reason for this is that constructors aren't synchronised and can't have the synchronised keyword applied but then two threads can't be constructing the same object.
So, to avoid this, you should never expose this in your constructor. One way of doing so is to call non-final methods. Doing so, say calling an abstract method, allows some unknown code to do something with your unfinished object. Obviously, this can't be done if you initialise in your declaration.
p.s. I thought there was something on this in Effective Java but couldn't find anything.