On 4/22/2020 4:32 PM, Dan Smith wrote:
Another module system sanity check: is mutual recursion allowed between unnamed
modules of different loaders? (Pre-9, mutual recursion between different
loaders was certainly possible...)
Yes. Anything that was possible with class loaders on JDK 8 is
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
> On Apr 22, 2020, at 1:38 PM, Dan Smith wrote:
>
> Iterating on the JVMS changes for sealed types, I've been refining the
> details of the runtime check.
>
> Two assertions, which I want to validate:
>
> - The run-time modules of a subclass and a sealed superclass must be the same.
> - The
> On Apr 22, 2020, at 4:48 PM, Alex Buckley wrote:
>
>>> 2a) If the superclass belongs to a different run-time module, error.
>
> As Remi says, by the time class loading happens, a layer has already been set
> up to map modules (and hence their packages) to loaders. JVMS 5.3.6 discusses
>
On 4/22/2020 1:43 PM, Remi Forax wrote:
2a) If the superclass belongs to a different run-time module, error.
2b) If the superclass doesn't have the subclass's name in its PermittedSubtypes,
error.
2b doesn't need to load anything, because 2a has guaranteed that both classes
have the same
Iterating on the JVMS changes for sealed types, I've been refining the details
of the runtime check.
Two assertions, which I want to validate:
- The run-time modules of a subclass and a sealed superclass must be the same.
- The defining class loaders of a subclass and a sealed superclass must
