On 19/07/2016 19:38, Paul Benedict wrote:
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.
Configurations are immutable. The primary use of empty() is to serve as
the parent for the Configuration of the boot layer.
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.
Yes, you probably want something like this:
Configuration parent = Layer.boot().configuration();
Configuration cf = parent.resolveRequires(ModuleFinder.of(), myfinder,
Set.of("myroot"));
To resolve "myroot" and its transitive dependences to create a new
configuration. The two finders that you are specify are the before and
after finders. The details is in the javadoc. In this example then the
before finder is empty (doesn't find any modules) so it will attempt to
locate the modules in the parent configuration. If not found there then
they will be located with "myfinder". Whether you use a before or after
ModuleFinder will depend on whether you need to overriding modules in
the parent configuration or not.
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()
Concealed packages are packages that are not exported. If you don't add
them then they will not be package of your module.
When creating a Configuration (like in the above) then they are
important to know when doing post resolution checks. It's an error, an
example, for your module M to have a package `p` and for it to read
another module that exports package p to M.
It's also important at runtime that the VM knows all the packages in the
module. Continuing the example, then suppose that class p.Foo is loaded.
The VM knows that this is in module M because you told it in advance
when defining the module to the VM. There is nothing in the the Foo
class file to help.
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.
There are a few warts in the Builder API that will be resolved soon. The
original intention was to detect mis-uses as early as possible and not
delay to the build() method. A package cannot be both concealed and
exported at the same time for example. So assumed this will be cleaned up.
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?
We use the ConcealedPackages class file attribute [1] as an optimization
to avoid scanning. Also for the modules in the run-time image then we do
a lot at link-time to minimize the cost of reconstituting the module
descriptors at run-time.
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.
Layers (think leaf layers) are intended to be discarded and
re-instantiated (probably from a new configuration).
-Alan
[1] http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html#jigsaw-2.3
