<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
Hi Uwe,
<blockquote type="cite" cite="mid:05a9ab99-2d99-251b-fc3d-9d5dae30d8c5@apache.org">
<ul>
<li>If there are changes again would that mean we get another
preview round? --- unfortunate!</li>
</ul>
</blockquote>
<br>
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.<br>
<blockquote type="cite" cite="mid:05a9ab99-2d99-251b-fc3d-9d5dae30d8c5@apache.org">
<ul>
<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>
</blockquote>
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 :-)<br>
<p>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).</p>
<p>Maurizio</p>
<br>
</body>
</html>