Why does the inReady method of StreamDecoder swallow IOException?

[Xueming Shen]

Jeff,

It appears StreamDecoder.inReady()/implReady() works this way, silently swallow
the IOE, from the very beginning/jdk1.4.0. This design/implementation probably was
based on the assumption that the InputStream.available() only throws the IOE when
the input stream has been closed by calling its close() method, as the InputStream.available()
spec suggests. Since the StreamDecoder.isReady()/implReady() is guaranteed to be
invoked under synchronized/ensureOpen() protection, the IOE should never occur. But
it appears this assumption might be incorrect as/if the underlying InputStream.available()
might throw an IOE when the stream is still open/has not been closed via a reader's
close() method, which does not appear to be against the spec.

@exception  IOException if an I/O error occurs.

Is this issue only reproducible on the latest jdk1.8.x and works fine with previous version?
If that is the case, it's possible that we might have a different "bug/issue" somewhere
else that the input stream is getting closed without by its reader's close() method.

regard,
Sherman

On 11/15/2017 03:11 PM, Jeff Evans wrote:
> Hello,
>
> We are dealing with an issue where an underlying exception appears to
> be getting swallowed by the StreamDecoder class.  In particular, the
> Jersey client library we are using (which happens to be version
> 2.25.1) is throwing an IOException out of its implementation of
> InputStream#available
>
> https://github.com/jersey/jersey/blob/master/core-common/src/main/java/org/glassfish/jersey/internal/util/collection/ByteBufferInputStream.java#L143
>
> by way of calling checkThrowable
>
> https://github.com/jersey/jersey/blob/master/core-common/src/main/java/org/glassfish/jersey/internal/util/collection/ByteBufferInputStream.java#L127
>
> The caller of that is ultimately StreamDecoder#inReady.  We are seeing
> the problem under Oracle JDK 1.8.0_121, but it seems the StreamDecoder
> code hasn't changed in a while:
> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/nio/cs/StreamDecoder.java#l366
>
> Is there some issue with the way the Jersey library code
> implementation, or potentially some issue with our code that is
> resulting in this exception not being propagated out from
> StreamDecoder?  Any insight is appreciated.
>
> Full stack trace image here: https://i.imgur.com/AuyYFAp.png