> 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. >> >> >> >> >