[foreign] Panama EA - August 2019 edition

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Wed Aug 28 10:11:25 UTC 2019


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.

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


More information about the panama-dev mailing list