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

John Rose john.r.rose at oracle.com
Tue May 22 01:19:57 UTC 2018

On May 21, 2018, at 5:48 PM, David Holmes <david.holmes at oracle.com> wrote:

*

A nest 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 nest host 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

More information about the core-libs-dev mailing list