> > This is the type of use-case where using Lookup objects might be a > better choice. If you can coerce the user module to pass a suitably > privileged Lookup to the framework then the framework will be able to > inject classes without needing to open packages to the framework. I > think this is an area where we need framework maintainers to do more > exploration. >
Yes, but we have found this to be equally tedious when you are trying to aggregate multiple modules. Because every module has to supply their own Lookup object. 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. 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. /Kasper
