Prev: Class Constants - pros and cons
Next: IllegalAccessError - Super/sub-types loaded with different classloaders
From: Lew on 25 Jul 2010 15:31
Lew wrote ...
>>>> In general, using a different classloader breaks inheritance.
>>

Mike Schilling wrote:
>>> Which is why all classes must be loaded by the same system classloader
>>> that loads Object :-)

Or by children thereof, in a parent-first order, so that the classes are in
fact loaded by the same loader, not by children of the one that loads
'Object'. I guess. I'm still learning how classloaders work.

Lew wrote ...
>> You seem to have found one of the exceptions that breaks the "in
>> general" rule, thus illustrating why I said "in general" in the first
>> place.
>>
>> Perhaps I should have said, "In general, using a different classloader
>> risks breaking inheritance unless you plan accordingly." I foolishly
>> thought that was implicit in stating the general risk, but I guess
>> some people need things spelled out in more excruciating explicit
>> detail than others. ;-)

Mike Schilling wrote:
> In fact, all non-system classes have ancestors from the system
> classloader, but you know that.
>
> From what I've seen, subclassing in a child classloader is quite safe
> [1]. What risks are you warning about?

If the classloader is not a child of the one that loaded the putative parent
class, then the putative child class will not inherit properly. As pointed
out upthread, app servers are known to reverse classloader order to
child-first loading, so in such an environment you can break hierarchies in
loaded classes. I've seen it happen.

The situation is exacerbated by JAR hell. You can load instances of a
particular class from incompatible JAR versions. I've seen that happen, too.

I'm not sure that child-first classloading preserves hierarchies even when the
classloader's parent loads the target class's parent. The rules state that
each classloader forms its own namespace, so in a child-first situation you
can load, say, log4j's 'Category' as the parent of its 'Logger' with one
classloader, and the same classes separately through another loader, and the
upcast 'Category categ = someLogger' would therefore fail if in that moment
you somehow crossed classloaders.

--
Lew
From: Lew on 25 Jul 2010 15:35
Lew wrote: ...
>>>>> In general, using a different classloader breaks inheritance.

Mike Schilling wrote:
>>>> Which is why all classes must be loaded by the same system classloader
>>>> that loads Object :-)

Lew wrote: ...
> Or by children thereof, in a parent-first order, so that the classes are
> in fact loaded by the same loader, not by children of the one that loads
> 'Object'. I guess. I'm still learning how classloaders work.
...
>>> You seem to have found one of the exceptions that breaks the "in
>>> general" rule, thus illustrating why I said "in general" in the first
>>> place.
>>>
>>> Perhaps I should have said, "In general, using a different classloader
>>> risks breaking inheritance unless you plan accordingly." I foolishly
>>> thought that was implicit in stating the general risk, but I guess
>>> some people need things spelled out in more excruciating explicit
>>> detail than others. ;-)

Mike Schilling wrote:
>> In fact, all non-system classes have ancestors from the system
>> classloader, but you know that.
>>
>> From what I've seen, subclassing in a child classloader is quite safe
>> [1]. What risks are you warning about?

Lew wrote: ...
> If the classloader is not a child of the one that loaded the putative
> parent class, then the putative child class will not inherit properly.
> As pointed out upthread, app servers are known to reverse classloader
> order to child-first loading, so in such an environment you can break
> hierarchies in loaded classes. I've seen it happen.
>
> The situation is exacerbated by JAR hell. You can load instances of a
> particular class from incompatible JAR versions. I've seen that happen,
> too.
>
> I'm not sure that child-first classloading preserves hierarchies even
> when the classloader's parent loads the target class's parent. The rules
> state that each classloader forms its own namespace, so in a child-first
> situation you can load, say, log4j's 'Category' as the parent of its
> 'Logger' with one classloader, and the same classes separately through
> another loader, and the upcast 'Category categ = someLogger' would
> therefore fail if in that moment you somehow crossed classloaders.

<http://articles.qos.ch/classloader.html>
shows how inheritance can be broken through classloader abuse.

--
Lew
First  |  Prev  | 
Pages: 1 2
Prev: Class Constants - pros and cons
Next: IllegalAccessError - Super/sub-types loaded with different classloaders