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
