JEP-353[1] which got implemented and released in JDK13, states:
"The java.net package defines many sub-classes of SocketException. The
new implementation will attempt to throw the same specific
SocketException as the old implementation but there may be cases where
they are not the same."
In
On 21/08/2021 08:17, Jaikiran Pai wrote:
JEP-353[1] which got implemented and released in JDK13, states:
"The java.net package defines many sub-classes of SocketException. The
new implementation will attempt to throw the same specific
SocketException as the old implementation but there may be
Hello Alan,
On 21/08/21 2:21 pm, Alan Bateman wrote:
On 21/08/2021 08:17, Jaikiran Pai wrote:
JEP-353[1] which got implemented and released in JDK13, states:
"The java.net package defines many sub-classes of SocketException.
The new implementation will attempt to throw the same specific
Sock
On 21/08/2021 12:40, Jaikiran Pai wrote:
I was able to reproduce this on a MacOS. However, the continuous
integration setup project for Quarkus projects runs these tests
against Linux and Windows setups and they have run into this issue at
least on the Linux OS jobs (I will need to go and check
Hello Alan,
On 21/08/21 9:56 pm, Alan Bateman wrote:
On 21/08/2021 12:40, Jaikiran Pai wrote:
I was able to reproduce this on a MacOS. However, the continuous
integration setup project for Quarkus projects runs these tests
against Linux and Windows setups and they have run into this issue at
This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
See https://github.com/openjdk/jdk/pull/5063 and
https://github.com/openjdk/jdk/pull/4951
In many places standard charsets are looked up via their names, for example:
absolutePath.getBytes("UTF-8");
This could be done more ef
