IOException is swallowed as a result of JDK class behavior

There appears to be an oddity in the behavior of `sun.nio.cs.StreamDecoder`, such that an `IOException` thrown from its underlying input stream's `available` method is silently swallowed. I will copy the relevant details from the [jdk-dev mailing list post](http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000206.html) to here.

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 - `2.25.1` - is throwing an `IOException` out of its implementation of `InputStream#available` (apparently when an `RST` packet is received from the peer terminating the connection). Specifically [here](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, as seen [here](http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/nio/cs/StreamDecoder.java#l366).

Full stack trace image [here](https://i.imgur.com/AuyYFAp.png). Is there any way in which Jersey can, or should, change its behavior so that this exception isn't swallowed? I realize that the ultimate issue appears to be within the JDK code, but nonetheless, the exception being lost is a problem. Any other suggestions are welcomed!