Iteration 3, https://gist.github.com/forax/c08ce0a8dc88705bce97b17b63e7e2d5
GrantAccess can now be put on a class, on a package or on a module, and give access to several frameworks by their names. Getting access to the lookup of a class is now a 2 steps process, first claim a framework name to get an AccessFacade and then through the AccessFacade, a framework have access to all classes annotated (directly or indirectly) by GrantAccess and allowing the framework. The facade corresponding to a framework name can only be requested once so how to store the FacadeAccess is let to the framework implementation and if a code try to sneak in and use a framework name it will be detected. Rémi ----- Mail original ----- > De: "David M. Lloyd" <[email protected]> > À: "Andrew Dinn" <[email protected]>, [email protected] > Envoyé: Mardi 1 Novembre 2016 21:00:35 > Objet: Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules > & open packages > On 11/01/2016 11:02 AM, Andrew Dinn wrote: >> On 01/11/16 15:35, David M. Lloyd wrote: >>> On 11/01/2016 10:09 AM, Andrew Dinn wrote: >>>> There is a very easy way to provide tightly controlled access to a >>>> framework. Export access to e.g. jdk.internal.misc.Unsafe or e.g. >>>> java.lang.[invoke].MethodHandles to a nominated module provided by your >>>> framework then arrange for that module to hand out Lookups (or better >>>> MethodHandles) to framework code as and when they are needed via a >>>> private channel. You can do arrange that with a single addExports option >>>> on the command line and a very small amount of setup code to establish >>>> the private channel >>> >>> I don't see how this is safer though. You're proposing to hand all the >>> keys (or none) to modules which don't need all the keys, whereas I >>> propose that a module should only gain incremental additional access on >>> a grant basis. >> >> No, I'm suggesting handing the keys to a single module provided by your >> framework -- which module will then use a key to open a room on demand >> for your code and your code only. That means the privilege can be >> granted using one command line switch with use of that privilege >> controlled by a runtime mechanism of your choosing. > > Yes, however that means that I'm on the hook to make sure that the keys > aren't mislaid. And given the fact of open modules - which already > semantically grants me privileges - requiring a special command line > switch (which is itself undesirable) and custom code to enable those > privileges in the *preferred* manner (i.e. MethodHandles) seems > backwards when open modules would already grant me the ability to > utilize a much finer instrument albeit with the legacy approach (i.e. > reflection). It seems quite logical to extend this mechanism to the > preferred MethodHandle approach instead, and forget about Unsafe and > anything like it, which I think is in everyone's best interests in the > long term. > >>> At least Rémi's approach requires a specific grant and non-Unsafe >>> vector, though as I said the weaknesses (of his first approach) are that >>> the grant must come from the target class (programmatically) instead of >>> being a static declaration ("opens" is a natural fit for this if I >>> understand the proposal correctly). The other weakness is that it >>> requires class init, but that's purely a consequence of requiring a >>> programmatic grant as far as I understand. >> >> I did actually suggest a way of avoiding the use of Unsafe. You give >> your nominated module full reflective access to java.lang.invoke >> allowing it to create Lookup instances (it can actually just create a >> single all privileges lookup and use this to clone others). You don't >> need to insert a class into java.lang.invoke to do this. You simply add >> one exports directive on the command line. > > That is marginally better, of course, but I think the rest of my > objections still stand against this argument. > >>> Rémi's newest Gist uses an annotation, which is closer but not quite on >>> the target IMO. An annotation cannot be module-deployment-agnostic in >>> the way that I outlined previously (hence >>> #IndirectQualifiedReflectiveAccess); ultimately accessibility >>> information ought to come from the module configuration itself. >> >> If you implement a module with the ability to hand out Lookup instances >> you can use whatever control model you like. For example, you might park >> an instance which hands out Lookups in a location only available to your >> framework or ensure that any caller asking for a Lookup belongs in a >> package implemented by your framework or whatever you want. the point is >> that once you have granted a class in our code the ability to create >> Lookups you can implement whatever runtime access control you want. >> Clearly,as John said, you need to do that responsibly. >> >> regards, >> >> >> Andrew Dinn >> ----------- >> Senior Principal Software Engineer >> Red Hat UK Ltd >> Registered in England and Wales under Company Registration No. 03798903 >> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander >> > > -- > - DML
