Module API usage questions

Paul Benedict pbenedict at apache.org
Tue Jul 19 18:38:40 UTC 2016


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


More information about the jigsaw-dev mailing list