|
Description
|
In order to allow legacy applications to take advantages of code packaged in modules, add a specially configured repository (called extension repository). If a module is installed in it, it will automatically be exposed in the extension classloader and thereby accessible to legacy apps.
Note that the extension repository is not a new repository type but typically just an instance of LocalRepository.
Posted Date : 2007-05-17 19:18:29.0
|
|
Evaluation
|
During VM startup, the installed extension modules are examined. The highest version of each module with the same name would be recognized, and its reexported would be expanded. When classes and resources are requested from the extension classloader, the JARs in the installed extension directory would first be examined. Then, the extension classloader would delegate to the classloader of each recognized extension module and its reexported modules would be used.
If there is more than one extension module with different names, the order which this classloader recognizes these extension module is undeterministric. The current implementation is based on the order of the module definitions returned from the extension repository, but this may change in the future.
An extension module must NEVER import the classpath module transitively. Otherwise, loading classes through this extension module could trigger classloading through the application classloader which delegates to the extension classloader, and it will result in infinite loop. Thus, if an exension module imports the classpath omdule tranitively, it is ignored.
Posted Date : 2008-03-13 10:39:36.0
|