On 14.01.19 17:18, Kasper Nielsen wrote:
[...]
So you need some kind of bootstrap class in every module that registers
their Lookup object somehow. And, you also have to make sure that the
bootstrap class does not make the Lookup object available to someone who
should not have access to it. This is solvable, for example, by using a
ServiceLoader.
But now, you also have X number of Lookup objects you need to keep track
of. And then someone gets the idea that you need an extension
hierarchy that crosses module boundaries. So you end up with needing one
Lookup object for one method on an object and another Lookup object on
another method on the object. Because the first method is on an abstract
class located in another modul.
Maybe I understood something wrong, but assuming
Module A
public abstract class A {
public abstract void foo();
}
Module B (reads A)
public class B extends A {
public void foo(){}
public void bar(){}
}
then in Module C to call bar on an instance of B I need a Lookup object
with the correct rights for B. But I can use the same Lookup object to
call foo on an instance of B.
If B does not read A when loading the class B I would actually expect
the module system to deny loading the class... never tested that though.
Is that not the case?
In the end it might just be simpler to add an open statement for every
package in your module-info. At least for some use cases.
For many cases in which you have to load things dynamically. If not, you
can figure out these things statically and patch the modules to have the
right settings, which means to make a tailored module loading in the end.
bye Jochen
