ClassLoaders, jars and subclassing

[Rainer Schwarze]

Hi,

I am working on a plugin implementation (yes, another one )
Lets assume I have a few classes in a few jars:

class X in x.jar (with main method)
class A in x.jar (together with X)
class B in b.jar
class C in c.jar
class ASub (extends A) in asub.jar

I run X.main in the x.jar.

In X a URLClassLoader is created with urls to b.jar, c.jar and asub.jar.
The classes A and C have a method (say touchB) which creates an instance
of B and calls a method from B. (It is doing that by something like: B b
= new B(); b.method(); )

Well, the following happens:

- I can create instances of the classes A, B, C, and ASub in X - I use
the reflection API for that.

- "C.touchB" can find class B
- "A.touchB" cannot find class B (gives an InvocationTargetException)
- "ASub.touchB" cannot find class B (gives an InvocationTargetException)
(I put the C.touchB and the others in quotes, because I do it with the
reflection API and not "directly".)

Looking at the ClassLoaders of B, C, and ASub reveals, that they use the
URLClassLoader. Class A has the system class loader.

Now what I do not fully understand is:
Why does ASub cannot access B?

I thought, that a class has a class loader associated and uses that to
access a class. ASub has URLClassLoader and by that can access b.jar
where the class B is located. However, class A was created by the system
class loader and thus cannot see class B. To me that means, that if I
put a subclassed class into a plugin which is loaded by a custom class
loader and the super class lies in the system class loaders scope, I
will get problems.

Do I see the situation correctly?
Does someone has hints about how to solve such a problem "the right way"?

(The basic problem I have is: Has anyone succeeded in "dynamically
loading" PLaF's by "including" jars (for instance with URLClassLoader)
from a subdirectory which are not in the original classpath for the
application?)

Best wishes,
Rainer

 

[Chris Uppal]

- "A.touchB" cannot find class B (gives an InvocationTargetException)

I take it that this is what you expect to happen ? (It's what /I/ think should
happen anyway.)

- "ASub.touchB" cannot find class B (gives an InvocationTargetException)

And I I'm assuming that the code that actually does the "touch" is inherited
from A, rather than duplicated in ASub. Also I'm guessing that you are using
the simple form Class.forName(String) rather than specifying a classloader
explicitly.

Now what I do not fully understand is:
Why does ASub cannot access B?

The wording of the definition of Class.forName(String) is unfortunately
ambiguous, it doesn't make it clear whether the "current classloader" is the
classloader of the class of the executing object, or that of the class where
the executing method is defined. If the above assumptions are correct, then
what you are seeing suggests that the implementation in fact uses the
classloader of the class where the method is defined.

I think you should be able to code around it by re-writing the code in class A
to use:

c = Class.forName(
"a.class.name",
true,
this.getClass().getClassloader());

To me that means, that if I
put a subclassed class into a plugin which is loaded by a custom class
loader and the super class lies in the system class loaders scope, I
will get problems.

It certainly suggests that you'll have to keep your wits about you and think
carefully about /which/ classloader is invoked by which code.

(BTW, for your "dynamic PLaF" problem, if the equivalent of class A is
Sun-supplied system code, then I'm afraid I don't know of a workaround. That
doesn't mean there isn't one (I know little of PLaFs). It might be worth
starting a new thread explicitly on that topic.)

-- chris