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

[Maurizio Cimadamore]

Hi Uwe,
>
>   * If there are changes again would that mean we get another preview
>     round? --- unfortunate!
>

This seems to be indeed the case for most of the stuff we finalize. E.g. 
Loom and amber feature were finalized pretty much "as is" after a round 
of very (very) light changes. In fact, finalizing FFM API after a 
signifiant round of API changes would have represented the exception, 
not the norm.
>
>   * 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?
>
The naming issue is a tricky one. On the one hand, I can relate to what 
you say. On the other hand, creating an automatic arena is still 
creating a _group_ of resources (e.g. you are still opening something - 
the difference is just that you don't have to call close yourself). 
Which means there's constraints pushing us in different direction: the 
semantics side of things tell us that the three methods should be named 
similarly; the try-with-resource side of things would push for having 
the confined/shared names stand out a bit more. Honestly, it feels like 
we could debate this aspect for a very long time and be none the wiser :-)

The warning is a known issue. Most IDEs seem to have a check for calling 
methods on an AutoCloseable directly (e.g. outside a 
try-with-resources). So, if you do `Arena.global().allocate(...)` you 
get a warning. This was partly why, in 20 we have tried to split the API 
more between closeable and non-closeable types, but I believe the lesson 
we learned is that the benefit we get out of that is not worth the 
complexity cost. I would assume that some of these warnings will be 
rectified, at least in cases where it's obvious they are false positives 
(or maybe, if that proves too difficult, just dropped if the static type 
happens to be Arena). I don't think this situation applies to the javac 
compiler (although javac has other cases in which false positives 
warnings are generated for AutoCloseable, such as when you use them in 
"lock" style, but these do not affect FFM API).

Maurizio

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230517/b2dd56b4/attachment.htm>