[foreign] Panama EA - August 2019 edition

[Maurizio Cimadamore]

On 30/08/2019 17:59, Ty Young wrote:
>
> On 8/28/19 5:11 AM, Maurizio Cimadamore wrote:
>> I just want to clarify on this point below; the foreign memory access 
>> work does not, in any way, hinder the higher level functionalities 
>> provided by the foreign API/binder. We arrived at the foreign memory 
>> access API because we felt that something low level was missing - 
>> e.g. that the high level Pointer API was doing too much at once; and 
>> that users not interested in a high-level API, but still wanting to 
>> access off-heap data would not be served very well by the Pointer API 
>> alone.
>>
>> So, moving forward you can expect the bulk of the foreign API to be 
>> relatively stable (well, it's a prototype, so we might tweak things 
>> here and there); what will really change is how this API is 
>> _implemented_ - that is, moving forward the foreign API will be built 
>> _on top_ of the lower memory access and ABI layers. But high-level 
>> use cases using jextract need not to worry about this.
>>
>> I hope this clarifies better where we'd like to land.
>
>
> Yes, it does greatly. Thanks for clarifying.
>
>
> Speaking of the Pointer API, could a method be added to wrap a pointer 
> in another pointer for **char string pointers? AFAIK, the only way to 
> do that is:
>
>
> <LIB>.scope().allocate(<LIB>.scope().allocateCString("").type().pointer()); 
>
>
>
> ...which gets the Pointer<Pointer<Byte>> type that I need but I'm not 
> entirely sure if this is the correct way to go about getting the type. 
> Using the layout of a throwaway pointer layout just seems wrong and 
> wasteful.

If you want to allocate a Pointer<Pointer<Byte>> you can do this:


<LIB>.scope().allocate(NativeTypes.UINT8.pointer());


Maurizio


>
>
>>
>> Cheers
>> Maurizio
>>
>> On 19/08/2019 10:33, sundararajan.athijegannathan at oracle.com wrote:
>>>>
>>>> All that said, how close is Panama? Is this foreign memory API 
>>>> going to stay going forward or will the project take a major shift? 
>>>> I'd *really* like to start putting this to use and am willing to 
>>>> make adjustment where needed if minor changes are made, but if the 
>>>> entire foreign API is scrapped it isn't worth it.
>>>
>>>
>>> Panama "memory access" ("memaccess" panama-dev branch) API is 
>>> expected to become stable first and then other parts of java.foreign 
>>> later ("foreign" branch stuff).