Re: RFR[14] 8236098:AlgorithmConstraints:permits method not throwing IAEx when primitives are empty

2020-01-07 Thread Xuelei Fan
Looks fine to me. Thanks, Xuelei On 1/7/2020 11:40 AM, Anthony Scarpino wrote: FYI, there is no test included because the JCK test already exists. On 1/7/20 11:39 AM, Anthony Scarpino wrote: Hi, I need a code review for a JCK issue where the AlgorithmConstraints spec says that permits() wit

Re: RFR[14] 8236098:AlgorithmConstraints:permits method not throwing IAEx when primitives are empty

2020-01-07 Thread Anthony Scarpino
FYI, there is no test included because the JCK test already exists. On 1/7/20 11:39 AM, Anthony Scarpino wrote: Hi, I need a code review for a JCK issue where the AlgorithmConstraints spec says that permits() with a null or empty primitives throws an IllegalArgumentsException.  The code curre

RFR[14] 8236098:AlgorithmConstraints:permits method not throwing IAEx when primitives are empty

2020-01-07 Thread Anthony Scarpino
Hi, I need a code review for a JCK issue where the AlgorithmConstraints spec says that permits() with a null or empty primitives throws an IllegalArgumentsException. The code currently allows no primitive and continues with the check. Additionally, there was a needed change to JSSE SeverHel

Re: Reading from a closed socket: different behavior between Linux and other operating systems

2020-01-07 Thread Lothar Kimmeringer
Am 07.01.2020 um 09:19 schrieb Dawid Weiss: I can understand how this behavior can be considered platform-dependent but it's still a bit surprising that it shows consistent behavior on everything except Linux... (we originally thought it's Windows to be blamed here). Not the only one. Open,

Re: [14] RFR JDK-8229243 "SunPKCS11-Solaris provider tests failing on Solaris 11.4"

2020-01-07 Thread Archana Nogriya
Hi, We have noticed that, src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11gcm2.h has been added couple of month back, and in new copyright added with GPLV2 but there is no mention of Classpath exception. Since this code is part of release and distributed please can I request you to add

Re: Reading from a closed socket: different behavior between Linux and other operating systems

2020-01-07 Thread Dawid Weiss
Thank you for your feedback. I can understand how this behavior can be considered platform-dependent but it's still a bit surprising that it shows consistent behavior on everything except Linux... (we originally thought it's Windows to be blamed here). For the SSL layer I implemented a workaround

Re: Reading from a closed socket: different behavior between Linux and other operating systems

2020-01-07 Thread Simone Bordet
Hi, On Mon, Jan 6, 2020 at 5:39 PM Chris Hegarty wrote: > // force RST > clientChannel.setOption(StandardSocketOptions.SO_LINGER, 0); Just want to point out that when the channel/socket is set in non-blocking mode, SO_LINGER is either not supported or gives undefined behavior or throws (