<html><head></head><body> <div dir="auto">Hi,</div><div dir="auto"><br></div>Great news ! Congratulations to you and your team for reaching this point. And thank you a lot for taking time helping and advising us !<div dir="auto"><br></div><div dir="auto">Cheers,</div><div dir="auto"><br></div><div dir="auto">Martin<br><div><br></div> <div id="protonmail_mobile_signature_block"><div dir="auto"><caret></caret><br></div></div>Le jeu. 27 juil. 2023 à 15:57, Maurizio Cimadamore <<a class="" href="mailto:Le jeu. 27 juil. 2023 à 15:57, Maurizio Cimadamore <<a href=">maurizio.cimadamore@oracle.com</a>> a écrit :<blockquote type="cite" class="protonmail_quote"> Hi all,<br>As you know, the FFM API has been a Preview API since Java 19 [1]. The<br>API was then re-previewed in 20 [2] and 21 [3]. Some of enhancements<br>delivered in this timeframe were:<br><br>* Unification of memory segments and memory addresses [4]<br>* Treat arenas as "capabilities", so that memory segments can be safely<br>shared [5, 6]<br>* Allow for custom arenas [5, 6]<br>* Add ways to customize linkage requests [7]<br>* Add fallback linker, to facilitate porting FFM API to all platforms [8]<br><br>We now believe that the FFM API is largely stable, and that, modulo<br>disasters :-), it should exit preview in the next Java SE release:<br><br>https://openjdk.org/jeps/8310626<br><br>We have already started accumulating some changes in the panama<br>repository which aim at polishing some minor edges in the API:<br><br>* Add better support for "wide" native strings [9]<br>* Make var handles derived from layouts more composable [10]<br>* Add a linker method that can be used to discover platform-dependent<br>mapping between C types and layouts [11]<br><br>These changes are fairly minor, and should not have a big impact (if any<br>at all) on existing code using the FFM API.<br><br>Of course, the fact that FFM API is headed for finalization doesn't mean<br>that development on FFM API will stop. There are several enhancements<br>(aside from "regular" performance fixes) that we have been discussing<br>over the years which can be delivered as follow-up JEPs:<br><br>* Support for unsigned/complex types (needs Valhalla)<br>* Mapping between structs and records [12]<br>* Integration between Linker and JNI [13]<br>* Structured arenas (depends on finalization of StructuredTaskScope) [14]<br>* Pinning of heap segments<br><br>(Of course, we have made sure that all the above enhancement can be<br>delivered in an additive fashion, e.g. without the need to make<br>incompatible changes to the FFM API)<br><br>Finally, we'd like to thank all the developers who, over the years, have<br>taken the time to take the API for a spin, try to build something with<br>it and report feedback. This has been a long journey, and we wouldn't be<br>where we are now without your help.<br><br>Cheers<br>Maurizio<br><br>[1] - https://openjdk.org/jeps/424<br>[2] - https://openjdk.org/jeps/434<br>[3] - https://openjdk.org/jeps/442<br>[4] - https://cr.openjdk.org/~mcimadamore/panama/segment_address.html<br>[5] - https://cr.openjdk.org/~mcimadamore/panama/session_arenas.html<br>[6] - https://cr.openjdk.org/~mcimadamore/panama/scoped_arenas.html<br>[7] - https://git.openjdk.org/panama-foreign/pull/734<br>[8] - https://git.openjdk.org/panama-foreign/pull/770<br>[9] - https://git.openjdk.org/panama-foreign/pull/836<br>[10] - https://github.com/openjdk/panama-foreign/pull/840<br>[11] - https://git.openjdk.org/panama-foreign/pull/839<br>[12] - https://github.com/openjdk/panama-foreign/pull/833<br>[13] - https://mail.openjdk.org/pipermail/panama-dev/2023-May/019079.html<br>[14] - https://cr.openjdk.org/~mcimadamore/panama/session_arenas.html<br><br></blockquote></div></body></html>