|
Description
|
The classloading for components and shared libraries should be implemented as follows (according to the JBI spec):
* The JBI classloader contains jbi classes and optionally some container's specific classes
** Normally they should be separated in two classloaders inheriting from each other, but for now it corresponds to the system classloader initialised by petals-bootstrap-launcher).
* A component's classloader has all its shared libraries (in their declaration order) as parents (or if no shared libaries, the JBI classloader as parent).
* A shared library has the JBI classloader as parent
* Component or SLs can be parent-first or self-first, in the first case, the default, they first look at their parent and then at their own classes; in the second case, they first look at their own class, then at their parents.
So there is a flat organisation of classloaders with the JBI classloader at the top, then inheriting from it, some SLs, then, for each components, they inherit from a set of SLs or if this set is empty, they directly inherit from the JBI classloader.
The current classloading implementation has some shortcomings:
* The parent JBI classloader is queried many times during the class resolution.
* Classloaders acts as bottleneck (Java 7 introduced a per-class locking mechanism), and even more if the JBI classloader is so often queried.
* The class hierarchy that implements it does not reflect properly the spec (there is only one object that takes care of dispatching to SLs classloader), so it introduces complex code in some places.
* It seems that sometimes the spec is not respected (but it's hard to be completely sure because the code is complex because of previous point).
* getResources is not implemented w.r.t. the JBI specs.
* The same with getPackage and getPackages... (which are used by code such as loadClass).
* Code comments are not up-to-date.
|
The classloading for components and shared libraries should be implemented as follows (according to the JBI spec):
* The JBI classloader contains jbi classes and optionally some container's specific classes
** Normally they should be separated in two classloaders inheriting from each other, but for now it corresponds to the system classloader initialised by petals-bootstrap-launcher).
* A component's classloader has all its shared libraries (in their declaration order) as parents (or if no shared libaries, the JBI classloader as parent).
* A shared library has the JBI classloader as parent
* Component or SLs can be parent-first or self-first, in the first case, the default, they first look at their parent and then at their own classes; in the second case, they first look at their own class, then at their parents.
So there is a flat organisation of classloaders with the JBI classloader at the top, then inheriting from it, some SLs, then, for each components, they inherit from a set of SLs or if this set is empty, they directly inherit from the JBI classloader.
The current classloading implementation has some shortcomings:
* The parent JBI classloader is queried many times during the class resolution.
* Classloaders acts as bottleneck (Java 7 introduced a per-class locking mechanism), and even more if the JBI classloader is so often queried.
* The class hierarchy that implements it does not reflect properly the spec (there is only one object that takes care of dispatching to SLs classloader), so it introduces complex code in some places.
* It seems that sometimes the spec is not respected (but it's hard to be completely sure because the code is complex because of previous point).
* getResources is not implemented w.r.t. the JBI specs.
* Code comments are not up-to-date.
|
Task
Resolved
Major
getPackage and getPackages should be reimplemented for ComponentClassLoader in order to take the shared libraries into account, but it doesn't seem to be so easy to do so.
The problem is technical and conceptual: