Channel should extend Closable

[jhaye]

Is your feature request related to a problem? Please describe.

Channel currently only implements AutoClosable. It was added to the standard library as a super interface to Closable, so that everyone could benefit from the try-with-resources feature, without changing API. This also means that pretty much all APIs designed to consume something with a close method, do so via the Closable interface. Since AutoClosable is above Closable in the the hierarchy, those APIs cannot work with Channel.

Describe the solution you'd like

The Channel interface implements Closable. This extends the super interface set and is thus an API compatible change.

Describe alternatives you've considered

No response

Additional context

No response

[acogoluegnes]

This also means that pretty much all APIs designed to consume something with a close method, do so via the Closable interface.

Which APIs are you referring to?

[michaelklishin]

@jhaye please submit a PR? (just to make sure: we want to keep AutoClosable but adding Closeable sounds reasonable)

[jhaye]

Which APIs are you referring to?

Apache Commons IOUtils is a good example. close and closeQuietly take Closable as an argument, but this wouldn't work with Channel. The underlying code is quite simple, so I supsect, that similar APIs exist in many corporate code bases.

[jhaye]

@jhaye please submit a PR? (just to make sure: we want to keep AutoClosable but adding Closeable sounds reasonable)

Gladly, I was initially not sure how my employer handles contributions to OSS. I resolved that question now and will open a PR soon. Since Closable is a sub interface of AutoClosable, so this change would automatically keep AutoClosable.

[jhaye]

Well... I overlooked that Channel's close also contains TimeoutException in its signature. Since that extends from Exception, and Closable requires IOException only, I don't think anything can be done here in an API-preserving way.

Looking over the issue tracker, it appears that a next major version is in the works. Maybe this could be adressed there? Otherwise feel free to close this.

[acogoluegnes]

Channel#close() throws IOException and TimeoutException, I don't think there is a non-breaking solution to make Channel implement Closeable.

IOUtils targets stream-related classes (InputStream, etc), which all implement Closeable. It does not target interfaces like Channel. And its API was designed before Java 7.

A java.io.Closeable is a source or destination of data that can be closed.

A java.lang.AutoCloseable is an object that may hold resources (such as file or socket handles) until it is closed.

Note the phrasing and the package for each interface. Channel is closer in concept to AutoCloseable than it is to Closeable. I understand this is confusing because Connection does implement Closeable, but I don't think it was a good decision, it should have been AutoCloseable instead.

We are reasoning backward if we want Channel to implement Closeable: "APIs designed to consume something with a close method" should accept AutoCloseable, not Closeable. It is like an iteration API that can consume only List: we are not changing Set or Collection to implement List, the API should accept Collection.

[acogoluegnes]

Looking over the issue tracker, it appears that a next major version is in the works. Maybe this could be adressed there Otherwise feel free to close this.

There is no ETA for 6.0. TBH, I would rather make Connection implement AutoCloseable instead of Channel implement Closeable in 6.0. That would be a first move toward getting rid of the checked exceptions in the library.