What’s the consequence? Select one.
A. Compilation fails.
B. NullPointerException is thrown at runtime.
C. ClassCastException is thrown at runtime.
D. The next is printed:
SuperS
SuperM
SubS
SubM
E. The next is printed:
SuperS
SuperM
SuperS
SuperM
Reply. This query investigates some elements of how Java resolves entry to static components in a kind. On this query, the scenario appears to be difficult for a number of causes.
◉ The reference variable v is asserted utilizing var reasonably than an express sort identify comparable to SuperS.
◉ The qualifying prefix to the static components is a variable reasonably than a category identify.
◉ The variable v that’s used as a prefix incorporates a null reference reasonably than pointing to an precise object. You may see this as a result of the static discipline superS shouldn’t be explicitly initialized within the code and, as such, is assured to be initialized to null.
◉ It seems that the general public static discipline msg within the dad or mum class is shadowed by a non-public discipline of the identical identify within the subclass.
Contemplate the primary of these points. On this query, the var pseudotype is used to request that the compiler infer the kind of the variable v from the kind of the expression used to initialize v. That expression is the static discipline superS, which has sort SuperS and the worth null; subsequently, v can be of sort SuperS and has the worth null. From that time ahead, there isn’t a distinction within the habits of the variable v from how it could behave if it had been given an express sort. Particularly, var doesn’t create dynamic typing in the way in which that happens in languages comparable to JavaScript and Python.
From this, you recognize that this declaration
var v = superS;
is equivalent in impact to the next express kind
SuperS v = superS;
and, on this case, it has equivalent impact to this type
SuperS v = null;
Notice using a reference variable (v), as an alternative of a category identify, because the prefix in an expression referring to a static ingredient. Java borrowed loads of C++ syntax, and a type of syntax components is the flexibility to make use of an occasion expression as a prefix in the way in which used right here. When static strategies had been added to interfaces in Java 8, this capacity was not propagated to that function, presumably as a result of it creates ambiguous code.
Given this syntax, there’s an inclination to imagine that the reference is adopted to the precise object, after which the ingredient (discipline or methodology) is present in that object (which roughly describes the habits if the ingredient in query had been an occasion function). Nevertheless, this isn’t a sound mannequin for the habits with static components. Static components belong to the category, to not any explicit occasion of that class. The compiler creates code that merely determines the goal class and obtains the ingredient from that. Discover there’s nothing like late binding or polymorphism occurring on this case. As a facet word, there’s additionally nothing of that kind occurring with occasion fields; late-binding habits relates solely to overridable occasion strategies.
This tells you that the worth of the prefix object is completely irrelevant as a result of it performs no half in accessing static components. That illuminates the remaining items of this a part of the puzzle: It doesn’t matter if the reference is the null worth, as a result of it’s by no means used.
Additionally, casting the worth to the subtype and reassigning it, as within the following line, can be irrelevant:
v = (SubS) v;
An task like which may change the worth of the variable (though right here it doesn’t), however it can not change the kind of that variable, which is decided completely by its declaration. Certainly, nothing can change the kind of a variable at runtime, regardless that the forged on the best of the task does create a short lived expression that has the forged sort.
Yet one more difficulty to think about is whether or not a shadowing variable in a subclass may be much less accessible than the variable that it shadows, as is the scenario with the 2 msg fields on this instance. Maybe surprisingly, that is permitted.
Why would possibly that be a shock? Nicely, broadly, the Liskov substitution precept tells you that substitute components in a baby sort mustn’t trigger surprises when they’re in contrast with their unique components in a dad or mum sort. For that reason, an overriding methodology in Java can’t be much less accessible than the overridden methodology, can not declare checked exceptions that aren’t permitted from the overridden methodology, and (considerably simplified) should present an assignment-compatible return sort. Nevertheless, these are static fields, one shadowing the opposite, not overriding strategies, in order that they’re not likely substitutes, and it seems that they’re not topic to the identical guidelines.
What’s maybe odder is that if a static methodology in a category hides a static methodology in a dad or mum class, the tactic within the subclass is topic to those guidelines regardless that it’s not likely overriding both. However, since each methodology() strategies are declared public on this query, that doesn’t trigger an issue right here.
From this, remembering that the kind of the variable v is SuperS, you possibly can decide that the code will print the textual content from the SuperS class twice, and it’ll by no means print the textual content from the SubS class. You additionally know that no errors are reported throughout compilation or execution. Subsequently, the proper reply is choice E and choices A, B, C, and D are incorrect.
Conclusion. The right reply is choice E.
