URLClassLoader problem with inner classes

Thread view:

axel - 25 Aug 2006 16:42 GMT

Hello,

I have an abstract base class A with some function in a standard
package. And then I have a class B extends A with a lot of inner
classes. B is loaded by the URLClassLoader and also initialized with a
static initialize function cause B is designed as a singleton. In the
(private) ctor I create from every inner class 1 object and store it in
a hashmap.
The problem comes later if I want to access a function of A from an
inner class of B and I get this error:
"e"= IllegalAccessError (id=105)
cause= IllegalAccessError (id=105)
detailMessage= "tried to access method cmdpkg.A.foo()S from
class cmdpkg.B$_B1"
stackTrace= null

Where is the mistake. Is it a problem if the base class A is known
before and also in the jar for class B?

Thanks, Axel

Reply to this Message

Thomas Hawtin - 25 Aug 2006 17:54 GMT

> I have an abstract base class A with some function in a standard
> package. And then I have a class B extends A with a lot of inner
> classes. B is loaded by the URLClassLoader and also initialized with a

At a guess, your problem is that classes loaded by different class
loaders are effectively in different packages.

Tom Hawtin

Signature

Unemployed English Java programmer
http://jroller.com/page/tackline/

Reply to this Message

Chris Uppal - 25 Aug 2006 18:00 GMT

> I have an abstract base class A with some function in a standard
> package. And then I have a class B extends A with a lot of inner
[quoted text clipped - 9 lines]
> class cmdpkg.B$_B1"
> stackTrace= null

I'm a bit confused about what you are doing here, so this may be hogwash....

If you have attempted to put A and B (plus its nested classes) into the same
package, but have loaded the classes through different classloaders, then they
are /not/ in the same package (just two packages with the same name). So if
your B (or its nested classes) refers to members of A which are not public or
(in some cases) protected, then it'll fail. It'll fail at runtime rather than
compile time because javac doesn't realise that you are going to use different
classloaders.

-- chris

Reply to this Message

Ben Kraufmann - 25 Aug 2006 18:19 GMT

> Hello,
>
[quoted text clipped - 16 lines]
>
> Thanks, Axel

Hi.

Is A.foo() a public function or is it package?
If it is package, the problem is, that B and A are not in the same
package! You are loading B with your own ClassLoader. So the full
qualified class name is lets say myCL.cmdpkg.B. However, A is
appLoader.cmdpkg.A, where appLoader is the default application class
loader. This means, that your local A and your remote B are not in the
same package and A's foo() must have public visibility to be called from
within your remote B.

Ben

Reply to this Message

axel - 28 Aug 2006 08:12 GMT

Thank you all for your answers. And all answers have the same content:
The function A.foo() is protected and I have to make it public.
But I don't know the following (but I will try it in the next minutes):
I have also defined an interface Ibase and I have a class where I
register objects of THIS interface. But was is if B is implementing
this interface which comes from my class loader and the register class
want interfaces from the standard class loader? Is my way thinking
about this is wrong?

Thanks, Axel

Ben Kraufmann schrieb:

> > Hello,
> >
[quoted text clipped - 29 lines]
>
> Ben

Reply to this Message

Chris Uppal - 29 Aug 2006 09:02 GMT

> But I don't know the following (but I will try it in the next minutes):
> I have also defined an interface Ibase and I have a class where I
> register objects of THIS interface. But was is if B is implementing
> this interface which comes from my class loader and the register class
> want interfaces from the standard class loader? Is my way thinking
> about this is wrong?

Sorry, but I can't really understand that paragraph.

Anyway, as far as I can tell you have a scheme where there's an interface which
the classes loaded via your classloader must implement, and which is known and
used by a class which is not loaded via your classloader. If so then that's a
pretty standard arrangement, and should work OK. The thing to do is to ensure
that the interface is loaded from outside your custom classloader, and that
that classloader's parent (or possibly grandparent or other ancestor) is the
one that loaded the interface.

-- chris

Reply to this Message

axel - 29 Aug 2006 12:35 GMT

All works fine and it works like you have descirbed. But my question
was, if the interface comes also from the class loader and there exist
one from the standard class loader, then exist 2 interfaces from this
moment. But I have seen in the meantime that the interface is not
loaded abain by the URL class loader.

axel

Chris Uppal schrieb:

> > But I don't know the following (but I will try it in the next minutes):
> > I have also defined an interface Ibase and I have a class where I
[quoted text clipped - 14 lines]
>
> -- chris

Reply to this Message

URLClassLoader problem with inner classes

Free Magazines