…ules
In PR #805 I discovered (after hint from @jlahoda) that the bootstrap modules
actually leak all their content into dependent modules. So if a module depends
on o.o.filesystems, it would get all the classes in that module - and because
the `o.o.filesystems` (in `platform/lib`) is loaded by the same classloader as
`o.n.startup` (in `platform/core`), such dependent module would get
`objectweb.asm` and all core impl classes for free, although they were in
non-public packages.
There are two bugs fixed by this PR. First is that jars in `platform/lib`, the
real bootstrap, are loaded by the same classloader as jars in `platform/core`.
The `core` classes are one architecture level up, and should not be seen by
`lib` classes. This is fixed in `ModuleSystem.java` by going first through the
`lib` classes, then again through (remaining) `core` classes. Assuming the
`o.o.u.Lookup`'s classloader is only able to find resources in `lib`.
The second issue is caused by "covered package" cache, which registers
classloader(s) responsible for loading a certain class. For classes in `lib`
and `core`, this is always `MainImpl.BootClassLoader`, but that one lacks
completely module information (does not implement `Util.ModuleProvider`). The
`ModuleManager.shouldDelegateResource then cannot reach module package export
and friend information and cannot evaluate access restrictions.
I changed `ModuleManager` so that it remembers loader -> {module} relation for
fixed modules, and if `null` (unknown) module is passed to
`shouldDelegateResource`, it filters the bootstrap modules to find direct
dependencies of the current module, and then executes "usual" evaluation
procedure, this time with proper module info.
[ Full content available at:
https://github.com/apache/incubator-netbeans/pull/844 ]
This message was relayed via gitbox.apache.org for [email protected]
