On Jul 5, 2017, at 10:59 AM, Paul Sandoz <paul.san...@oracle.com> wrote: > > I strongly suspect we can specify a safe version of > Unsafe.defineAnonymousClass (minus constant pool patching) independent of > nest mates. I believe that is desirable on it’s own as part of the replace > unsafe functionality and if that can help MVT then even better!
We have an API point already for this, with a pre-planned "hole" for the functionality you want. If the VCC says "L=MethodHandles.lookup().in(DVT.class)" the Lookup should retain the PRIVATE access mode. Then, L.defineClass(...) is specified to throw an exception when it sees the PRIVATE access mode, but what is supposed to happen in the future is that the newly defined class is inserted into the nest of the Lookup.lookupClass. In the very specific case of a DVT, it would be reasonable to allow the injection you want, Paul, without throwing the required exception. After all, the DVT's are going away, so there's no compatibility risk for future changes to the API. The challenge to provide this for general use is to specify what happens when the Lookup has PRIVATE access mode. The best way to spec. this (IMO) is as a forcible injection into the nest of the Lookup.lookupClass. That requires nestmates to be specified *first*, and *then* we can specify what it means to inject a new (dynamically defined) nestmate. — John
