[sealed] Runtime checking of PermittedSubtypes

Alex Buckley alex.buckley at oracle.com
Wed Apr 22 23:59:56 UTC 2020

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.


More information about the amber-spec-experts mailing list