Enthuware

It took me quite a while to get my head around it. Now, looking back, I think the explanation is a bit confusing - to my taste.

I would say:

a.i cannot be accessed from class B. For that, a's type reference must be B, or a subclass of B. Instead, its type reference is A.

Since the access rules are typically explained in tutorials at a fairly early learning stage, the details fade out in memory as time passes. Therefore, it pays off to refer to the language specs directly.

I will leave your comment here for the benefit of others.

This code does not compile for the reason listed in the answer, then I don't understand why "None of the above" is marked as the right answer and "It will not compile" as wrong answer. I suppose this is a mistake in the test, the right answer should be "It will not compile".

"It will not compile" is indeed marked as the correct option.
-Paul.

Coming back to this Q after a few weeks I thought I still couldn’t understand, but shortly after looking at this page again (maybe badbishop’s line helped a bit?) I think it clicked, if this is a valid description:

When in a different package you need to use the subclass reference to take advantage of inheritance to access the protected superclass field. If you try to access the field on the superclass reference, the compiler see the call as trying to access it ‘directly’ from the superclass (only possible if the field is declared public), so complains.

If not, I’m still befuddled But then
class Cannelids implements Confusable{...

Cannelids wrote:When in a different package you need to use the subclass reference to take advantage of inheritance to access the protected superclass field. If you try to access the field on the superclass reference, the compiler see the call as trying to access it ‘directly’ from the superclass (only possible if the field is declared public), so complains.

I think this explanation helped me understand something I had gotten wrong since the OCA exam.

Yeah, Cannelids explanation is what did it for me too. I would say this:

If your reference is to class A, then that would be the same as using reference A from a completely different class.

Class Strange { // extends/implements nothing
A a = new A();
a.i = 42; // compiler error.

So since the reference A a is for A, then class B can't use it's superpower to access the protected variable. The reference has to be B for him to use his A-subclass privileges, or else it will be just like class Strange trying to access a.i. It makes sense but in mind this question is really tricky. Maybe because I have never used protected in my own code.

I like Cannelids answer but I would explain it simply like this:

Protected means you can only access it if you are a subclass OR within the same package. A a = new B() and then calling a.i fails both of these rules. A is not a subclass of A, and we are in a different package (package p2).

I could never truly grasp the logic behind protected keyword, hence I memorized the following axioms to handle protected members:
Within its home package a protected variable is effectively public. For all other cases, given a class A that declared a protected variable and a class B that is a subclass of A, an access to protected variable outside its home package is granted 1) only within class B and 2) only via a reference of type B or subclass of B.