P.S. Bottom line: Fail-fast is easier to get right, and therefore is preferable, unless there is (as Brian points out) some use case which benefits from the lazy checks. I think that separately compiled nests are a likely use-case, but it would *not* be a problem if malformed nests failed to load. It would be a faster indication of a bug in the compile-time logic, which had fouled the nest.
> On Feb 16, 2016, at 3:30 PM, John Rose <[email protected]> wrote: > > On Feb 13, 2016, at 7:24 AM, Brian Goetz <[email protected] > <mailto:[email protected]>> 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. > > — John
