13

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!

Pepijn Schmitz
  • 2,143
  • 1
  • 17
  • 18
  • I should add that Road$4 is an anonymous inner class of Road (obviously), but I also included that fact in my test case, and it still worked. – Pepijn Schmitz May 05 '12 at 20:21
  • 1
    possible duplicate of [Overriding default accessor method across different classloaders breaks polymorphism](http://stackoverflow.com/questions/4060842/overriding-default-accessor-method-across-different-classloaders-breaks-polymorp) – axtavt May 05 '12 at 22:40
  • @axtavt: you may be right, although that article is about default access, not protected access. I guess the same applies to protected access though. I did look at the spec, but didn't catch the "runtime package" thing. It doesn't explain why my test case works. I'll see if I can make it break using this knowledge. Thanks! – Pepijn Schmitz May 06 '12 at 01:06
  • 1
    @axtavt: The reason I didn't catch it is that I checked the language spec, but this is in the VM spec. The spec contains an additional interesting clause: "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." This explains why Road is allowed to access Seed.garden (it is a subclass of Seed), but Road$4 is not (it is not a subclass, and while in the same package, it is in a different runtime package). Now to break my simple test case... – Pepijn Schmitz May 06 '12 at 01:39
  • @PepijnSchmitz That may validate my answer below. Even though the "rule" is in the language spec, the reason it may be there is because of how a runtime interprets where an anonymous class belongs in the package structure. –  May 10 '12 at 16:07

4 Answers4

8

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!

Pepijn Schmitz
  • 2,143
  • 1
  • 17
  • 18
  • Thanks quite helpful. One thing to add - you needn't make those protected fields public you need only put a method in the sub class (And it can be private) which returns those values that are protected. It is only the anonymous class that is unable to access the protected fields not the sub class. – Michael Wiles Apr 14 '15 at 15:43
  • @MichaelWiles thanks. That was actually what I meant with my second suggestion. :) – Pepijn Schmitz Apr 15 '15 at 13:24
  • Solved my confusion. – twlkyao Feb 02 '19 at 08:34
4

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/

Mattias Isegran Bergander
  • 11,811
  • 2
  • 41
  • 49
  • It's not a class identity crisis (every class is only loaded by one classloader), but I believe the cause to be similar, as pointed out in the question axtavt linked to above, namely the fact that the classes are in different "runtime packages". – Pepijn Schmitz May 06 '12 at 01:38
  • I'm not sure what the difference is, what is "runtime package" you are referring to, are you referring to the different namespaces introduced by classloaders? Then we are talking about the same thing. – Mattias Isegran Bergander May 06 '12 at 10:27
  • Yes. "Runtime package" is what the Java Virtual Machine Specification calls the combination of a package and class loader. I thought that by "class identity crisis" you meant loading the _same_ class twice using different class loaders. – Pepijn Schmitz May 06 '12 at 11:28
  • 1
    Ah well then we mean the same thing but should perhaps call it package identity crisis then :) – Mattias Isegran Bergander May 06 '12 at 11:31
  • Then why public methods or files are not limited by different classloader @MattiasIsegranBergander – twlkyao Feb 02 '19 at 08:19
  • Public methods and fields are well... public.Accessible by anyone, really anyone, across classloaders included. Well unless you have some sort of modularity on top of it limiting the scope , such as OSGi etc. But OSGi runtimes usually a hard time (fail/complain) when multiple bundles exporting the same package. – Mattias Isegran Bergander Feb 02 '19 at 21:55
1

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.

  • Interesting information. I think it doesn't apply though, because protected implies package access, and the inner class is in the same package (in my case) as the superclass of its enclosing class, so it should have access to the protected members of the superclass. Right? Otherwise it should not even compile, which it does. – Pepijn Schmitz May 06 '12 at 01:04
0

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.

miks
  • 514
  • 2
  • 5
  • It's not a simple permissions error, otherwise it would not even compile. But I think we found it, see my comments to the original question. – Pepijn Schmitz May 06 '12 at 01:45
  • by permission - I mean runtime permission, not static/compile time. Anyway it seems you found the real problem. – miks May 06 '12 at 10:24