Some Classes with a public void close() don't implement AutoCloseable

[forax at univ-mlv.fr]

A couple of points,
- it can be fixed by making TWR using a functional type instead of a nominal one
  by supporting a syntax like try(expr) { }. But this is in the same realm of ideas as allowing the enhanced for loop to use a an Iterator::iterator, so it has been rule out has a step too far by the lambda EG.
- until lambdas are retrofitted as inline types, i'm worry people will use forceTryable with a ReentrantLock,
   try(var __ = forceTryable(lock::unlock)) { ... } 
  because most of the time, the lambda will not be allocated but not always, sometimes it may still be found escaping by the JITs.
- my preferred fix is, as you already, know to remove the concept of checked exceptions from the language instead of spending time running in circles around them.

Rémi

----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Johannes Kuhn" <info at j-kuhn.de>, "discuss" <discuss at openjdk.java.net>
> Envoyé: Jeudi 16 Avril 2020 23:31:49
> Objet: Re: Some Classes with a public void close() don't implement AutoCloseable

> Nice.  I tried to find a way to make this a little more generic
> and came up with an API which handles arbitrary exceptions
> and is packaged as a method instead of a special idiom.
> There’s a natural-enough method called `forceTryable` that
> could be created.
> 
> http://cr.openjdk.java.net/~jrose/jdk/ForceTryableDemo.java
> https://bugs.openjdk.java.net/browse/JDK-8243015
> 
> (There are further generalizations of this, if you look at it as
> a “named cast method” for a functional interface type related
> to AutoCloseable.  See my comment on JDK-8243015.)
> 
> — John
> 
> On Apr 15, 2020, at 8:53 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>> interface FakeAutoCloseable extends AutoCloseable { public void close(); }  //
>> suppress exception
>> 
>> XMLReader xmlReader = ...
>> try(FakeAutoCloseable __ = xmlReader::close) {
>>  …