Hi,
Am 17.05.2023 um 00:41 schrieb Maurizio Cimadamore:
On 16/05/2023 19:03, - wrote:
For FFI, I would prefer some parts of the FFI, especially generic ones
like Indirect Var Handles, to be promoted from the preview status.
They are useful for non-FFI purposes.
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.
Has FFI API considered promoting APIs out of preview incrementally,
like how Virtual Threads and Scoped values are?
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).
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:
* 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).
* 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!
* 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?
I added panama-dev to CC.
Uwe
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.
Maurizio
Chen Liang
On Tue, May 16, 2023 at 12:28 PM Remi Forax <fo...@univ-mlv.fr> wrote:
----- Original Message -----
From: "Uwe Schindler" <uschind...@apache.org>
To: "core-libs-dev" <core-libs-dev@openjdk.org>
Sent: Tuesday, May 16, 2023 5:38:32 PM
Subject: JEP 442: Foreign Function & Memory API => why is it again
preview API?
Hi,
Hi Uwe,
yesterday Apache Lucene got the information that JDK 21 got the
project
panama JEP 442 update and I implemented it already in our source tree.
Unfortunately the API is again marked "preview", but JDK 21 is "LTS
release". Many of our users (Elasticserach, Solr) will be switching to
this version. We were really hoping that the java.lang.foreign API is
finished at that time. I checked the changes in our code: just a
rename
of a method and FileChannel#map now takes Arena instead of Scope.
I see that Alan and Maurizio have already answer to your other points.
Having preview features and being a LTS are to separate concerns.
Being a LTS is about support, having preview features is about
having feedback before finalizing an API.
Java 17 was released with preview features, Java 21 will be.
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.
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 :)
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.
Uwe
regards,
Rémi
--
Uwe Schindler
uschind...@apache.org
ASF Member, Member of PMC and Committer of Apache Lucene and Apache
Solr
Bremen, Germany
https://lucene.apache.org/
https://solr.apache.org/
--
Uwe Schindler
uschind...@apache.org
ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr
Bremen, Germany
https://lucene.apache.org/
https://solr.apache.org/
