john.r.rose at oracle.com
Tue Feb 16 23:30:17 UTC 2016
On Feb 13, 2016, at 7:24 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> On 2/12/2016 5:04 PM, Bjorn B Vardal wrote:
>> • The Top<->Child handshake only needs to happen when the Child is loaded (which will load Top as a dependency), and access request from Child1 to Child2 is reduced to Child1->nestTop == Child2->nestTop. This means that we can fail immediately if the handshake fails during class loading, i.e. it should not be postponed until a private access request fails. Do you agree?
> I think we have some options here:
> - We could fail fast, rejecting the class.
> - We could simply load the class into a new nest containing only itself; access control (in both directions) that would depend on nestmate-ness would fail later.
> I think the choice depends on whether we expect to see failures here solely because of attacks / broken compilers, or whether we can imagine reasonable situations where such a condition could happen through separate compilation.
The decision also influences when the Top class is loaded. If we fail fast, the Top is loaded as a prerequisite to loading the Child (much as loading the Child's supers is a prerequisite). If we fail lazy, then Top can be loaded the first time somebody tries a cross-nest access, but not until then. There are other orderings, but these two are the simplest to implement. I think overall the fail-fast option is the easiest to implement. But it does create a potentially surprising failure mode, which is not analogous to the failure modes for accessing other restricted names (protected, package, module). In those other cases, there is no need to load anything (or fail in the attempt) in order to answer an access control question. I like the idea that access control decisions are made on already-loaded data; it simplifies the model.
More information about the valhalla-spec-observers