[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