On 4/22/2020 4:15 PM, Dan Smith wrote:
Okay, so it would be valid to talk about "the run-time module of C"
while C is being derived?
I think this sentence from 5.3.6 anticipates this sort of early
query, but I might be misinterpreting the parenthetical:
"We say that a class is in a run-time module iff the class's run-time
package is associated (or will be associated, if the class is
actually created) with that run-time module."
I'm a little nervous about the idea that some associations haven't
happened yet. I'm not clear on the timing.
Yes, it would be valid. The wording of the 5.3.6 sentence is trying to
afford a degree of laziness to implementations in how they they make the
association between run-time package and run-time module. This is
because "run-time package" is a pretty ephemeral concept: before any
class is created, does any run-time package exist? Many implementors
would say "no" -- and yet, the invocation of ModuleLayer::defineModules
has already happened, so e.g. the VM has already associated the run-time
module `java.base` with the run-time package `java.lang` of the
bootstrap loader, even before the class `Object` is loaded. So, if you
have the name of a class, and a loader, you can find out from the VM
which run-time module the class has been or will be created as a member
of ("in"). The loader narrows down the run-time modules a bit; the
package name narrows them down further. The module:loader:package
relationships are immutable.
Alex
