brian.goetz at oracle.com
Fri Jan 22 15:04:02 UTC 2016
> If I understand correctly, the "top" class is there just to simplify
> the calculation of whether two classes belong to the same nest.
It's a little more than that, but this is part of it. Having a
canonical member simplifies the calculation of "are A and B members of
the same nest." Conveniently, there *is* an obvious canonical member,
so we might as well not make our life harder.
We need a way to refer to a nest. Having a canonical member is ideal
We need some way of (in)validating the claim "I am a member of the same
nest as java.lang.String". Having a canonical member, who can answer
such questions authoritatively, is ideal for that.
Because the intention is that "nest" corresponds to some logically
grouped source unit, and therefore a class may be a member of only one
nest, we need some way of enforcing that a nest forms a partition.
Having a canonical member makes this far easier.
> Are there any other functions that might be attached to the "top"
> class? Will the top class have to be loaded in order to verify access
> of one peer to another peer? Or will it just have to be parsed to
> extract the NestTop attribute?
The obvious implementation strategies would likely bring us there. It is
conceivable that we could delay loading the Top until its nest-ness
credentials are needed, but that seems like it would add a lot of
implementation complexity (and would keep us from failing fast.) So its
likely that this would happen.
However, this seems pretty likely without nestmate-ness too. How often
do we instantiate an enclosed class without loading the enclosing
class? (Never for instance inner classes.) It happens, but usually
only in cases where nesting is used "for organizational purposes only"
(and in those cases, the enclosing class is usually trivial.) So this
doesn't seem a terrible constraint to me.
What other functions did you have in mind for what the Top can do to
help its children?
More information about the valhalla-spec-observers