Its actually a bit more than that, you are not allowed to use an instance variable or call an instance method, on the super() expression... meaning you can't use them to evaluate the parameters for the super() call.
A follow-up question : Are statics okay and others not because of initialization order?
Is the following true? Statics are set up as each class is loaded (top-to-bottom in the
code), starting with the loaded (lowest) class, then its super class and on up toward
Object. Then initialization continues from the most super class on down, in each;
class parameters, then initialization code blocks followed by constructor code.
BEE MBA PMP SCJP-6
Joined: Mar 14, 2010
This works fine. So what difference does it make from the previous one?
Joined: Dec 24, 2009
@Shoeb :- I didn't get your question........
Joined: Mar 14, 2010
Constructor is calling static variable and static methods in the code above?
and the code that is written first shows the same, but i didn't get what the first code is trying to prove.
Firstly my apologies if it was wrong to have revived a 5 year old thread. I find this thread interesting and the following is my take.
Yes, the SCJP 6 (Kathy Sierra) mentions:
"Only static variables and methods can be accessed as part of the call to super()
or this()." I believe this should be interpreted as "In the event a variable or method is accessed as part of the call to super() or this(), than that variable or method should be static."
In the example given by Rob Spoor, he is indeed making a call to a static method as part of the call to super, meaning the super class constructor is invoked with the string value/literal retuned by the getString() method which is static. In Shoeb Sayyed's example, the call to super() does not involve any method or variable, but uses a string literal/value which matches with the super class constructor argument. This is perfectly fine too. However the static methods and the static variable in Shoeb Sayyed's superclass are not necessary, as in they are not relevant to the requirement that this thread is about. That is because the accessing of static variables/methods is only relevant when as part of the call to super() and not for calls made from the super constructor itself(though there is nothing wrong with doing that). The following modification of Shoeb Sayyed's code, with the static keyword stripped off the said variable and method, compliles just as fine:
So I think the important point is the line "as part of the call to super()"
Joined: Oct 13, 2005
No, there is nothing wrong about reviving old threads to add something relevant. And that post is relevant.
I am sure that is KS (who incidentally founded this website) wrote “only”, she meant “only”. Let's have a look at the Java® Language Specification, and see how much light it casts on that question.
It says (§8.8.7) that a constructor invocation must be the first statement of the constructor, which means super(...); or super(); or this(...); or this(); If you write one of those invocations then it is explicit and if you don't, then an implicit constructor invocation is created with super();. It also says (§188.8.131.52) that…
An explicit constructor invocation statement in a constructor body may not refer to any instance variables or instance methods or inner classes declared in this class or any superclass, or use this or super in any expression; otherwise, a compile-time error occurs.
That means that when KS wrote “only”, she meant “only”. No “should” about it, but definitely “must”. The JLS is quite definite about that.
It is potentially hazardous to refer to static fields directly or indirectly from a constructor because one does not necessarily know their values at object creation time, but it is permitted.So what do those two print instructions print out?
But it is even worse with instance fields.Now, the field field exists in Dog because I made the mistake of not declaring it as private. So what is going to happen if you run that constructor? Are you going to set field to an undefined value, or even to its default value of null? Are you not going to initialise the object in a consistent state? Think what runtime errors you would get.
You are right, that prohibition only applies to explicit constructor calls. You are permitted to use static members of the class because (as has already been said) they exist before any instances exist.
You may use instance members elsewhere in the constructor, although there are at least two pitfalls:-
1: The fields may not necessarily have been initialised.
2: If you use a polymorphic method, you may get a different version from what you expected.