<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi,<br>
</p>
<div class="moz-cite-prefix">Am 17.05.2023 um 00:41 schrieb Maurizio
Cimadamore:<br>
</div>
<blockquote type="cite"
cite="mid:bc2b336f-a205-e8d8-ed68-76d49c9b2d2e@oracle.com">
<br>
On 16/05/2023 19:03, - wrote:
<br>
<blockquote type="cite">For FFI, I would prefer some parts of the
FFI, especially generic ones
<br>
like Indirect Var Handles, to be promoted from the preview
status.
<br>
They are useful for non-FFI purposes.
<br>
</blockquote>
These parts (e.g. the additional var handle combinators in
MethodHandles) are the only ones that could be finalized
independently of the remainder of the FFM API, yes.
<br>
<blockquote type="cite">Has FFI API considered promoting APIs out
of preview incrementally,
<br>
like how Virtual Threads and Scoped values are?
<br>
</blockquote>
<br>
See my other email. FFM is composed of two biggie APIs, one for
managing memory, and one for linking foreign functions. The
lifetime abstractions cut across both APIs (and so do memory
layouts, which are used to deal with memory dereference, but also
to describe foreign types for the linker). So, I don't think there
were ever concrete opportunities to split the two APIs (even if it
would have been nice to do that).
<br>
</blockquote>
<p>I agree with that, it is hard to split. I was not aware that the
lifetime abstracions were such a huge issue! Why I was asking the
question:</p>
<ul>
<li>You changed the lifetime abstractions in Java 20 and again in
21. To me this is 2 rounds. After 19 people were not happy, so
you added 20. In 20 there was some additional cleanup (in my
impression it was a step back to Java 18 state just with
different class names: MemorySession -> Arena).</li>
<li>In 21 to me it looked that you are finishing up the API and
get to a final state. Now with preview features in mind: Does it
need to be in preview state whenever you change something again?
If there is only positive feedback in 21, you would release 22
with *unchanged* APIs just the preview annotations removed? If
there are changes again would that mean we get another preview
round? --- unfortunate!</li>
<li>If you want feedback to the changes in 21: I am mostly fine,
thanks for fixing FileChannel#map(). I strongly disagree with
the rename from Arena::openShared to Arena::ofShared. This hides
the fact that you need to use try-with-resources and close the
arena. If a method is named "open()" it is a hint for the
developer without reading the javadcos that this needs to be
closed. the global and automatic Arena can use prefix "ofXy" or
no prefix at all, but the confined and shared ones should use
open() to make it clear that theres smething to close. The main
problem is also that the java compiler or Eclipse gives you no
warning when using ofShared() (depends on the constellation). On
the other hand if you use global() it may produce a warning, as
the returned Arena is an Autocloseable instance. How is that
dealt with? Is the compiler using some method name matching when
producing a warning?<br>
</li>
</ul>
<p>I added panama-dev to CC.<br>
</p>
<p>Uwe</p>
<blockquote type="cite"
cite="mid:bc2b336f-a205-e8d8-ed68-76d49c9b2d2e@oracle.com">Sometimes
features can be decomposed nicely, and delivered incrementally.
That has been the case for most Amber features, and also for Loom.
Other times it is less practical to do so, as for FFM API, and
patterns in switch + record patterns.
<br>
<br>
Maurizio
<br>
<br>
<blockquote type="cite">
<br>
Chen Liang
<br>
<br>
<br>
On Tue, May 16, 2023 at 12:28 PM Remi Forax
<a class="moz-txt-link-rfc2396E" href="mailto:forax@univ-mlv.fr"><forax@univ-mlv.fr></a> wrote:
<br>
<blockquote type="cite">----- Original Message -----
<br>
<blockquote type="cite">From: "Uwe Schindler"
<a class="moz-txt-link-rfc2396E" href="mailto:uschindler@apache.org"><uschindler@apache.org></a>
<br>
To: "core-libs-dev" <a class="moz-txt-link-rfc2396E" href="mailto:core-libs-dev@openjdk.org"><core-libs-dev@openjdk.org></a>
<br>
Sent: Tuesday, May 16, 2023 5:38:32 PM
<br>
Subject: JEP 442: Foreign Function & Memory API =>
why is it again preview API?
<br>
Hi,
<br>
</blockquote>
Hi Uwe,
<br>
<br>
<blockquote type="cite">yesterday Apache Lucene got the
information that JDK 21 got the project
<br>
panama JEP 442 update and I implemented it already in our
source tree.
<br>
<br>
Unfortunately the API is again marked "preview", but JDK 21
is "LTS
<br>
release". Many of our users (Elasticserach, Solr) will be
switching to
<br>
this version. We were really hoping that the
java.lang.foreign API is
<br>
finished at that time. I checked the changes in our code:
just a rename
<br>
of a method and FileChannel#map now takes Arena instead of
Scope.
<br>
</blockquote>
I see that Alan and Maurizio have already answer to your other
points.
<br>
<br>
Having preview features and being a LTS are to separate
concerns.
<br>
Being a LTS is about support, having preview features is about
having feedback before finalizing an API.
<br>
<br>
Java 17 was released with preview features, Java 21 will be.
<br>
<br>
Before Java 10, when we were doing feature release model, if a
feature was not ready yet, either the release was delayed
(Java 9 was delayed 3 times if i'm remembering correctly) or
postponed to the next big release (Java Module was initially
scheduled for Java 8). With the new cadence model, features
that are not ready yet are marked as preview.
<br>
<br>
I understand that you are eager to use MemorySegment in anger
but since a looong time, Java features are only released when
they are ready :)
<br>
<br>
Also, it seems that we will have a LTS release every two years
now, if a LTS had no preview, it means that we will not get
any feedback for 1/4 of the releases.
<br>
<br>
<blockquote type="cite">Uwe
<br>
<br>
</blockquote>
regards,
<br>
Rémi
<br>
<br>
<blockquote type="cite">--
<br>
Uwe Schindler
<br>
<a class="moz-txt-link-abbreviated" href="mailto:uschindler@apache.org">uschindler@apache.org</a>
<br>
ASF Member, Member of PMC and Committer of Apache Lucene and
Apache Solr
<br>
Bremen, Germany
<br>
<a class="moz-txt-link-freetext" href="https://lucene.apache.org/">https://lucene.apache.org/</a>
<br>
<a class="moz-txt-link-freetext" href="https://solr.apache.org/">https://solr.apache.org/</a>
<br>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre class="moz-signature" cols="72">--
Uwe Schindler
<a class="moz-txt-link-abbreviated" href="mailto:uschindler@apache.org">uschindler@apache.org</a>
ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr
Bremen, Germany
<a class="moz-txt-link-freetext" href="https://lucene.apache.org/">https://lucene.apache.org/</a>
<a class="moz-txt-link-freetext" href="https://solr.apache.org/">https://solr.apache.org/</a></pre>
</body>
</html>