----- Mail original ----- > De: "Dan Smith" <daniel.sm...@oracle.com> > À: valhalla-...@openjdk.java.net > Envoyé: Mardi 18 Avril 2017 20:44:11 > Objet: Fwd: Draft JVMS changes for Nestmates
> For those not subscribed to (or not paying attention to) > valhalla-spec-experts, > I just posted a link to an updated draft of JVMS changes. > >> Begin forwarded message: >> >> From: Dan Smith <daniel.sm...@oracle.com> >> Subject: Draft JVMS changes for Nestmates >> Date: April 18, 2017 at 12:42:16 PM MDT >> To: valhalla-spec-experts@openjdk.java.net >> >> Hi, all. >> >> I've uploaded a draft of JVMS changes for JEP 181 "Align JVM Checks with Java >> Language Rules for Nested Classes" to: >> http://cr.openjdk.java.net/~dlsmith/private-access.html >> >> Some comments below on my thinking in drafting the spec text, and on the JEP >> generally. >> >> JEP name >> >> I don't know how permanent JEP names are supposed to be, but I'd prefer a >> different name at this point. Something like: "Expanded JVM Access to Private >> Members"—shorter, focused on the feature itself rather than its relationship >> to >> the Java language. Or maybe "Class Nests for Access to Private Members". >> >> Terminology >> >> The term "nest" is nice because it's short and mostly unspoiled by >> overloading >> in this context (I think?); it's not great because it's informal and doesn't >> mean anything the first time you hear it. I thought about something more >> clinical like "access control context", but I'm not convinced that's an >> improvement. How do others feel? >> >> The JEP uses "nest top" to describe the class that nest members reference; I >> prefer "host class", which better describes the class's role and isn't tied >> to >> the Java "top level class" concept. I know we use "host class" internally in >> Hotspot, perhaps when working with anonymous classes (of the JVM flavor), >> but I >> think in that context it will ultimately mean the same thing? Are we >> comfortable repurposing the term in this way? The semantics of an anonynmous host class and a nest host class are different. an anonymous host class is used for every access check while the nest host class is used Anyway, nest host class works for me. >> >> I follow Brian's model when it comes to nest membership (5.4.4): every class >> belongs to a nest, possibly (in the absence of MemberOfNest) the nest hosted >> by >> itself. Many nests are singletons without any associated explicit attributes. >> >> Verification of MemberOfNest >> >> I include a discussion block about different options of validating >> MemberOfNest. >> I think the consensus, and my preference, is to do it during verification of >> the member class. (NestMembers, on the other hand, is never validated, except >> as a side-effect of checking MemberOfNest.) It means that a NestMembers can contains Class that are not yet/never defined. It's not a problem for me. >> >> Verification of invokespecial >> >> Allowing invokespecial to refer to classes other than the current class and >> its >> supers is a significant change. I noticed and relied heavily on the parallel >> with invokevirtual making protected method calls. So I tried to make the two >> as >> similar as possible. In a few places, the treatment of protected methods >> doesn't seem ideal, and rather than trying to mirror that with non-private >> invokespecial, I modified the protected method treatment. >> >> The "protected check" of verification, in particular, was a mess before, and >> I >> think I've made it a lot more manageable, and compatible with a parallel rule >> for invokespecial. I could use some feedback on exactly what Hotspot's >> verifier >> has been doing here, though, since I'm pretty sure it didn't match the old >> specified rules. >> >> MethodHandle resolution >> >> The spec (5.4.3.5) is vague about what errors can occur during MethodHandle >> resolution. I assume any linkage error specified for the instruction can also >> occur via MethodHandle resolution, and that will include failures due to >> invokespecial improperly referencing a class. method handle behavior is the same as their corresponding bytecodes behavior, errors are converted to exceptions. >> >> Dynamic checking of invokespecial receivers >> >> When invokespecial involves interface types, the verifier can't guarantee >> that >> receiver objects actually implement that interface (JDK-8134358). It's an >> open >> question whether this is really a problem, but I included a tentative fix in >> the invokespecial runtime rules. I'm not sure it's related to nestmate ? >> >> Compiler changes >> >> The JEP text can't seem to decide if compiler changes are part of it, or a >> follow-up exercise. I think we're best off explicitly including the compiler >> changes, which will provide opportunities for design validation and testing. >> >> API changes >> >> I haven't tried to address changes that need to be made to APIs. Somebody >> will >> need to. For example, Lookup.findSpecial probably needs to make adjustments >> to >> account for private members in nestmates, and to parallel the new >> verification/linkage rules (e.g., follow Lookup.findVirtual in restricting >> the >> receiver type). >> >> Security risk >> >> The JEP text should acknowledge that, while this does allow compilers to >> grant >> finer-grained access to members shared by nestmates, it also pushes compilers >> to grant broader access to members that were previously kept private. It's a >> trade-off, and presumably a good one because nestmates are completely >> trusted, >> while package-mates might sometimes be suspect. >> >> (I guess this argument really ought to be made from the top: declaring things >> with package access is worse than inventing a new level of access because >> ________.) >> > > —Dan Rémi
