I have a few questions regarding how to use the module API. Thanks for reading.
1) Is Configuration.empty() meant to be an immutable singleton or a mutable empty configuration? Is it supposed to be analogous to Collections::emptyList/Map where it's a stand-in? I am asking based on the javadoc alone. 2) Must all modules that could ever be loaded be specified on the module path? I was hoping to find a hook where I could provide by own implementation of ModuleFinder that has all that knowledge self-contained. I think the answer may be Configuration::resolveRequires, but please confirm. 3) What is the difference between adding a concealed package and not adding the package at all? If no difference, I don't know why you would ever call ModuleDescriptor.Builder.conceals() 4) The aforementioned method (and all the others mostly) throws ISE if the package is already concealed or exported and you try to change it. But does the API really need a once-and-done requirement? You couldn't pass the builder instance across a chain of decorators, for example, and have them tweak each according to their own rules. 5) One of the criticisms (made to me) of scanning all packages for annotations (such as a theoretical @Exported on a package) was that it would take too much time. Okay.... However, the ModuleDescriptor is going to have an collection of all packages regardless because it provides packages() method. So is the data lazy or pre-initialized? 6) If Layers cannot be torn-down and recreated, what is the recourse to modules that come and go dynamically? If you say "it is not supported", then I don't see how one could adapt Configuration/Layer to applications where it's acceptable to drop in new artifacts and have them spin-up. The artifacts I have in mind are EE artifacts. It just sounds like nothing will change in the EE world then because it's impossible to use these new features there. Cheers, Paul
