JEP 442: Foreign Function & Memory API => why is it again preview API?

Wed May 17 07:28:12 UTC 2023

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 <forax at univ-mlv.fr> wrote:
>>> ----- Original Message -----
>>>> From: "Uwe Schindler" <uschindler at apache.org>
>>>> To: "core-libs-dev" <core-libs-dev at 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
>>>> uschindler at 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
uschindler at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20230517/0b9b8415/attachment-0001.htm>