> On 5 Jul 2017, at 11:06, John Rose <john.r.r...@oracle.com> wrote: > > On Jul 5, 2017, at 10:59 AM, Paul Sandoz <paul.san...@oracle.com > <mailto: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. >
Yes. > Then, L.defineClass(...) is specified to throw an exception when it sees the > PRIVATE access mode, Right, i was just looking at that, currently scoped for package access. > but what is supposed to happen in the future is that the newly defined class > is inserted into the nest of the Lookup.lookupClass. > I was unsure if we require a new method L.defineAnonClass or could leverage the existing L.defineClass. IIUC for expediency the current hooks in the VM lean towards anon classes, since there is already code to defer to the host class, whereas the general defineClass case will likely require more work, although i can potentially see some short cuts if we focus on VCC/DVT. Paul. > 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
