[core-libs] RFR (L): 8010319: Implementation of JEP 181: Nest-Based Access Control

[John Rose]

On May 21, 2018, at 5:48 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> * <p>A <em>nest</em> is a set of classes and interfaces (nestmates) that
> * form an access control context in which each nestmate has access to the
> * private members of the other nestmates.
> * The <em>nest host</em> is the class or interface designated to hold the list of
> * classes and interfaces that make up the nest, and to which each of the
> * other nestmates refer.
> +* All nestmates are implicitly defined in the same runtime package.

FWIW I agree that this would be a fine addition.  Note that this is
not something the API enforces; the JVM requires, as a structural
constraint, that the various nestmates all share a common package
prefix.  Pointing this out in the reflection API doc is useful but not
strictly required; it won't affect compliance or dictate behavior not
already specified (indirectly) elsewhere.

So all of the above text is descriptive and not the primary normative spec.
of how nestmates work; that normative spec. is in the JVMS, not javadoc.
For this reason, it's reasonable and low-risk to add clarifying text like
this; it doesn't change behavior, so much as help users understand it.
When I've written stuff like this in the past, sometimes I make the link
explicit, by saying something like "…as stated in the JVMS, this API
produces…".  Then we have a little classroom session about the
implications of the JVMS.  Not normative, but illuminating.

In fact, making the spec. more user friendly is a good thing to pay
attention to in the implementation review, even after is has passed the
CCC and spec. expert reviews, although I would expect those earlier
reviews to produce a reasonably user-friendly result.  That said, such
things can be added later, and I deeply sympathize with David's
"immutable object" stance.  Also (in a different way) with him having
to field documentation RFEs that are equally applicable across
pre-existing APIs.  I've noticed that when we really dig into our
specs. at new points, we suddenly realize that they could have been
much better all along.  I propose we note this and file a tracking bug,
rather than wedge the improvements into new spec. only.

An *implementation* code review should not, in general, reopen spec.
issues that have already been reviewed.  If I were David in this case,
I'd feel like some of these review points are making about the same
progress as a revolving door does.  I don't know what the full fix is,
but part of it has to be agreeing to partition the problem and work
on one part at a time.  Which we do, of course, as a habit, but it
seems some highly interconnected features like nestmates attract
expansive reviews.  We could say "well, it's a fundamental JVM
change" but does that mean we should also so 100x times this
expansive review process for value types?  If so, it's going to take
longer than any of us want.

And, for smaller RFEs like nestmates, it's going to be hard doing
the next several.  I hope the next few will get through the various
review gauntlets with more ease.  I'm thinking specifically of sealed
classes (and maybe fields), final-means-final, lazy fields, and
frozen arrays.  All of these are, like nestmates, smaller features
that cut across many layers of the system, and so will need multiple
facets of review.  If any (or all) of those happen, let's learn from
this experience and do even better next time.

I'm not unhappy with this experience, but want to do even better.
Buy David a beer to get his viewpoint.  And, thank you to everyone
who has put eyeballs on these reviews; they are crucial to getting
a good outcome.

— John