Can't access protected member of superclass from same package in different jar

Question

I\'m having a strange problem that I can\'t figure out that popped up when trying to pluginize my program. An additional problem is that I\'m not able to create a simple tes

Answer 1

This is permission error, so it depends on the framework you use to run your runtime. Just to clarify this is indeed this, make the parent member public, and then try to run. In case everything is ok, then restore your code, and according to the runtime you use we need to configure the correct security access.

Answer 2

OK, so with the help of axtavt and other respondents I figured out what the problem is. The other answers helped, but they didn't get it exactly right, which is why I'm answering my own question. The problem turned out to be the concept of "runtime packages", defined in the Java Virtual Machine specification as follows:

5.3 Creation and Loading

... At run time, a class or interface is determined not by its name alone, but by a pair: its fully qualified name and its defining class loader. Each such class or interface belongs to a single runtime package. The runtime package of a class or interface is determined by the package name and defining class loader of the class or interface. ...

5.4.4 Access Control

... A field or method R is accessible to a class or interface D if and only if any of the following conditions is true: ...

• R is protected and is declared in a class C, and D is either a subclass of C or C itself.
• R is either protected or package private (that is, neither public nor protected nor private), and is declared by a class in the same runtime package as D.

The first clause explains why Road is allowed to access Seed.garden, since Road is a subclass of Seed, and the second clause explains why Road$4 is not allowed to access it, despite being in the same package as Road, since it is not in the same runtime package, having been loaded by a different class loader. The restriction is not actually a Java language restriction, it is a Java VM restriction.

So the conclusion for my situation is that the exception occurs due to a legitimate restriction of the Java VM, and I'm going to have to work around it, probably by making the fields public, which is not a problem in this case since they are final, and not secret, or perhaps by exporting Seed.garden to Road$4 via Road, which does have access.

Thank you everyone for your suggestions and answers!

Answer 3

Sounds like you have a class identity crisis, having two different class loaders loading the same class in the class hierarchy or similar. Read up some on the java class loaders. Here is a good one for introduction, for "class identity crisis" see figure 2: http://www.ibm.com/developerworks/java/library/j-dyn0429/

Answer 4

I should add that Road$4 is an anonymous inner class of Road...

Someone else thought this was a bug as well back in 1998:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4116802

An inner class has no greater access to members of another class than a top-level class, except for those members that are declared within an enclosing, enclosed, or sibling class. It is a common misconception that an inner class has unrestricted access to inherited members of its enclosing classes. This is not true.

I would probably research that fact a bit more though because this was reported originally against Java 1.2, but I seem to remember from my reading that this is true today as well.

EDIT:

I confirmed this to be true:

http://docs.oracle.com/javase/tutorial/java/javaOO/summarynested.html

The scope for an anonymous inner class is only the point where it is defined. So it will not have access to inherited members, even if the outer class does.