Setting foreign.restricted to permit doesn't work

[Ty Young]

On 4/23/20 7:11 PM, Maurizio Cimadamore wrote:
>
> On 23/04/2020 22:43, Ty Young wrote:
>> Next question: what's going on with MemoryAddress handles? Presumably 
>> you need to do:
>>
>>
>> private static final VarHandle POINTER_HANDLE = 
>> MemoryHandles.varHandle(LONG_HANDLE, ByteOrder.nativeOrder());
>>
>>
>> To do what you could before. Is this correct and Is this because of 
>> all the new fancy methods added to MethodHandles? It surely can't be 
>> for type safety since VarHandles has none. 
>
> If you want a pointer handle you can first create a long handle (like 
> you did above) and then adapt it using 
> MemoryHandles::asAddressVarHandle - which will give you back a 
> VarHandle whose carrier type is MemoryAddress, not long.
>
> We moved back to a combinator-based approach since this gives us more 
> flexibility, and keeps the API simple. For instance, it is now 
> possible to create a VarHandle which gives you a MemoryAddress, but 
> out of a 32 bits read (e.g. where the 'base' VarHandle is an INT var 
> handle).


Huh, didn't realize the JDK was even still supporting 32-bit. It's 
pretty dead at this point.


I've rebased my main projects. It wasn't as smooth as usual because of 
(wait-for-it) the removal of the Nashorn JavaScript engine.


Yeah, Netbeans apparently used it to handle Java Modules in Ant based 
projects. I had to switch the build system over to Maven, which is "fun" 
for its own reasons.


Besides that, there were a few places in my code that manually created 
VarHandles instead of using the utility static method which of course 
failed, so I had to fix those. That's what I get for not consolidating code.


Anyway, thanks!




>
> Maurizio
>