In terms of what we have today we could easily do: // lookup must have private access to the lookup class, which becomes the “host” class Class<?> defineAnonymousClass(byte[] data)
is that ending gaining too much? That still leaves the possibility of another method in the future say: Class<?> defineClass(boolean isAnon, byte[] data, Object constant) That’s a little fuzzy since it’s not clear to me how the generated class locates the constant (synthetic static final field of known name? substitute the last entry in the CP if appropriately defined in the class bytes as substitutable?). Paul. > On 5 Jul 2017, at 11:43, John Rose <john.r.r...@oracle.com> wrote: > > On Jul 5, 2017, at 11:39 AM, Paul Sandoz <paul.san...@oracle.com> wrote: >> >> >> 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. >> > > Good point. Yes, that part isn't designed yet. It may manifest as an extra > argument or two to the L.dC. > > At least two degrees of freedom apply there: 1. suppressing the name (no > system dictionary update), > 2. providing some sort of "user data" to bind to the class (can be a single > ref., replaces CP patching). > > For MVT we can just generate a throwaway name, like DVT.getName()+":29348". > > — John
