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

Reply via email to