On 16/05/2023 16:38, Uwe Schindler wrote:
It exists now since Java 14, where it first appeared as incubation. I
know theres still work on the foreign linker, but why aren't the
stable classes like MemorySegment, ValueLayout not public now?
Hi Uwe,
while I understand the frustration (and I'm grateful for the feedback
you and others provided along the way), I think I disagree on this
assessment. While it's true that layouts and segments have not changed
much, the story about how to reason about the lifetime of a memory
segment has. So, yes, MemorySegment per se has not changed, but the way
in which you obtain segments has changed quite a bit.
Now, we could probably have finalized a subset of FFM which did *not*
support linking of foreign function **and** deterministic deallocation.
But would that have been useful? IIRC, Lucene has two main reasons to
use FFM:
* deterministically unmap memory-mapped memory segments w/o using Unsafe
* mapping files that are bigger than 2GB
While a MemorySegment-only version of FFM would have allowed the latter,
it would not have allowed for the former - meaning that there would be
still part used by Lucene that would be under "preview".
So, while we have considered such a splitting move many times (believe
me!), we always came up with the same conclusion: an FFM API w/o a story
on lifetimes would not be very useful compared to what's already
provided in the Java SE API.
Hopefully the lifetime-centric heavy-lifting is behind us. But I still
think it would have been too risky to finalize the FFM API with a
new-ish lifetime API that was not validated in the wild. As much as we
try to be responsible with API changes, and do code analysis on the code
using FFM code we know about, there's always a chance to miss something.
For this reasons, I'm a strong believer that, when in doubt, the answer
should always be "wait one more release" - at the end of the day that's
why we have 6-month releases to begin with.
Cheers
Maurizio
