<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 10/18/2022 1:52 PM, Brian Goetz
wrote:<br>
</div>
<blockquote type="cite" cite="mid:1b16ee1f-3d70-0993-b9b8-d6f0f865270f@oracle.com">
I come to the same conclusion as John, but from a slightly
different angle.<br>
<br>
First, I'm not thrilled with the idea of specifying TWR via
desugaring at all; it means that accidental artifacts of
specification end up being weighted too seriously. But I also
think that TWR suffers from failure of imagination (it is too
IO-specific) and also that it suffers from other accidental issues
(such as, using an interface for AC, which forces us to pick a
name that might be great for IO but lousy for arbitrary
resources. A type class would be better, when we have them.) <br>
<br>
So I would prefer to raise our sights on TWR towards the construct
we would like to work towards (just as we raised up switch from
the gutter of byte-stream parsing). <br>
</blockquote>
<p>There were extensive discussions during the development of
Project Coin / JSR 334 about using TWR for non-IO resources, in
particular locks. In the end, no specific accommodation was made
for non-IO types. From the JSR 334 PFD discussion:</p>
<p>
<blockquote type="cite">At least in Java SE 7, a class must have a
method named "close" to
implement the <code>AutoCloseable</code> interface and thus
work with
the <code>try</code>-with-resources statement.
To allow methods with other names like "dispose" to be called at
block
exit instead, an adapter interface with a matching factory can
be used
to wrap the object in question and forward calls from "close" to
the
type-specific clean-up method.
In the future, it is possible other mechanisms, such as
interface
injection, may also allow classes not declared to implement
<code>AutoCloseable</code> to be operated on by the
<code>try</code>-with-resources statement.</blockquote>
</p>
<p>-Joe<br>
</p>
</body>
</html>