Re: RFR: 8351339: WebSocket::sendBinary assume that user supplied buffers are BIG_ENDIAN [v4]

2025-03-18 Thread Daniel Fuchs
On Mon, 17 Mar 2025 17:29:11 GMT, beppo-sturmtief wrote: > Hi, original filer here. I don't know how you handle such things here, but 24 > files changed seems somewhat excessive to me for this bug. Yes - I had the same impression at first but AFAICT most of the [superfluous] changes are due to

Re: RFR: 8351339: WebSocket::sendBinary assume that user supplied buffers are BIG_ENDIAN [v3]

2025-03-18 Thread Mark Sheppard
On Mon, 17 Mar 2025 08:05:54 GMT, Volkan Yazici wrote: >> persisting with method nomenclature (or painting the bikeshed again). What’s >> in a name? >> >> reset is really init() or setMask() >> >> Currently you have a static applyMask() method and a non static >> applyMask() — is that

Re: RFR: 8325766: Review seclibs tests for cert expiry [v3]

2025-03-18 Thread Matthew Donovan
> This PR updates the CertificateBuilder with a new method that creates a new > instance with common fields (subject name, public key, serial number, > validity, and key uses) filled-in. One test, IPIdentities.java, is updated to > show how the method can be used to create various certificates.

Re: RFR: 8351339: WebSocket::sendBinary assume that user supplied buffers are BIG_ENDIAN [v4]

2025-03-18 Thread beppo-sturmtief
On Mon, 17 Mar 2025 07:52:43 GMT, Volkan Yazici wrote: >> Fixes endian handling `jdk.internal.net.http.websocket.Frame.Masker`. >> >> ### Implementation notes >> >> I deleted the `Frame` clone in tests, and rewired the test code depending on >> it to the actual `Frame`. To enable this, I relax

Re: RFR: 8325766: Review seclibs tests for cert expiry [v2]

2025-03-18 Thread Matthew Donovan
On Fri, 21 Feb 2025 13:47:59 GMT, Matthew Donovan wrote: > The similarity between the certificate pairs is impressive! Just curious - > why the change in issuer and owner names? After looking into this some more, I found that `X500Name(String dname)` is expecting the string to be in the same o