this has nothing to do with Apple, so maybe this is getting a wee OT,
but since that doesn't seem to stop anyone else ...
Mike Hall <email@hidden> writes:
>> you don't need reflection at all to use classloaders.
>>
> Not to use classloaders. To mix and match objects from different
> classloaders. I whipped up a test case. Turned out bigger than I meant and a
no. I repeat: you do not need to use reflection to use
classloaders, or to use objects from different classloaders. the
only reason you'd need to use reflections would be to defeat Java's
type and/or access protections schemes, neither of which is necessary
when using custom classloaders.
that said, using custom classloaders can be tricky, and can cause
unexpected things to happen. the main thing to keep in mind is that
a class is determined by both its name *and* the classloader that
loaded it. you could have a instance of a class whose name was
"Foo", but still have a cast (Foo) fail, if the Foo loaded by the
class making the cast was loaded by a different classloader than the
one that loaded the instance.
two classes with the same name but different classloaders are as
different as String.class and int.class.
in your (snipped) code, you make a reference to class Foo here:
TestMixedLoaders() {
Runnable r1, r2, r3;
try {
Class c1 = Class.forName(name);
r1 = (Foo)c1.newInstance();
System.out.println("r1=" + r1 + " class " + r1.getClass() + " loader " +
r1.getClass().getClassLoader());
r1.run();
}
The "Foo" in the cast above must have been loaded by the classloader
(or an ancestor) that loaded TestMixedLoaders (this would be the basic
"system" classloader), and *not* your custom classloader. that is, in
order for you to even run your test your program must have had
Foo.class somewhere on it's classpath. The Foo loaded by your custom
classloader is therefore totally unrelated to that Foo, and so the
cast fails, even though if you did a getClass().getName() you'd see
"Foo".
it's typical when doing this sort of thing to define interfaces (or
abstract base classes), and have the interfaces loaded by one
classloader (either the system classloader or a "parent" classloader
used just for this purpose) and then load classes through child
classloaders. that is, the parent of these classloaders is the one
that loaded the interfaces. you then can make casts to the
interfaces, but never to the names of the classes themselves.
--
joe
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
