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!
Paul. > On 5 Jul 2017, at 10:48, Karen Kinnear <karen.kinn...@oracle.com> wrote: > > Agree with John’s clarification - yes we are planning longterm for nest mate > access. > And your proposal of using a safe replacement for Unsafe.defineAnonymousClass > with > appropriate access to add into the nest makes sense. > > At this time we are building an Early Access that needs to go out sooner than > nest mates. > We should re-evaluate adding a nest mate dependency when we get closer to > deadlines and > see if that works for our partners and our own timing. > > thanks, > Karen > >> On Jul 5, 2017, at 12:28 PM, Paul Sandoz <paul.san...@oracle.com> wrote: >> >> >>> On 5 Jul 2017, at 07:26, Karen Kinnear <karen.kinn...@oracle.com> wrote: >>> >>> Paul, >>> >>> What we were discussing was the ability to use the byte code itself - not >>> the ValueType.findWither API. >>> John’s longer term plan is that ultimately the byte code can only be >>> executed in the value class itself, and >>> since the derived value class has no methods, we need a temporary approach. >>> >>> Did I misunderstand what you were saying? >>> >> >> No, i was missing aspect that you were referring to byte code generation. >> >> What if we added a safe replacement for: >> >> Unsafe.defineAnonymousClass >> https://bugs.openjdk.java.net/browse/JDK-8171335 >> >> (Which we anyway have to do.) >> >> ? > >> >> Then the VCC or DVT could be used as the host class. However, i dunno if >> that would be sufficient to cover the use-cases of byte code generation. > >> >> Paul. >> >>> thanks, >>> Karen >>> >>>> On Jun 26, 2017, at 2:52 PM, Paul Sandoz <paul.san...@oracle.com> wrote: >>>> >>>> >>>>> On 23 Jun 2017, at 13:33, Karen Kinnear <karen.kinn...@oracle.com> wrote: >>>> >>>>> VWithfield - propose for MVT - allow package private access - since there >>>>> are no methods on the derived value class >>>>> and the value capable class can’t have any methods with vbytecodes since >>>>> generated by javac >>>>> - plan to make private when we add factory methods to value classes with >>>>> a compiler (and we have nest support) >>>>> >>>> >>>> I am unsure if it’s necessary for MVT purposes to dial back the >>>> accessibility then dial it up again later on. >>>> >>>> ValueType.findWither can be used in conjunction with >>>> MethodHandle.privateLookupIn. It’s a little odd but works. What am i >>>> missing? >>>> >>>> Paul. >>>> >>>> >>>> >>>> >>> >> >
