Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

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!

like image 237
Pepijn Schmitz Avatar asked May 05 '12 20:05

Pepijn Schmitz


2 Answers

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!

like image 161
Pepijn Schmitz Avatar answered Oct 13 '22 01:10

Pepijn Schmitz


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/

like image 33
Mattias Isegran Bergander Avatar answered Oct 13 '22 01:10

Mattias Isegran Bergander