Missing a wildcard open statement

[Jochen Theodorou]

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