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 test case, because every time I try it works. There must be some complication I'm missing. But I'll try to describe the situation as clearly as possible, in case it sounds familiar to anyone.

I have a base class called Seed which is part of the main application and loaded by the system classloader. I have a plugin which contains a class Road which is a subclass of Seed. It is loaded at runtime from a separate jar file. The class Road references the field Seed.garden, which is defined as:

protected final Garden garden;

Note that I don't get compilation errors. I also don't get runtime errors when the plugin jar is included on the system classpath. Only when my main application loads the plugin using a new classloader (that has the system classloader as its parent) do I get the error. The error is:

java.lang.IllegalAccessError: tried to access field package.Seed.garden from class package.Road$4

It must have something to do with the fact that the subclass has been loaded by a different class loader than the superclass, but I can't find any official reason why that shouldn't work. Also, like I said, when I try to reproduce the problem with a simple test case (that includes the separate jars, loading the subclass with a different classloader, etc.), I don't get the error.

It also doesn't seem likely that I'm violating the access rules since it works when the classes are loaded by the same classloader, and I don't get compilation errors.

I'm out of ideas! Does anyone recognise this problem, or have some pointers for me for directions in which to look? Help!

Answer 1

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 2

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 3

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.

Answer 4

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.