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

[Michael McMahon]

On Mon, 17 Mar 2025 07:52:43 GMT, Volkan Yazici <vyazici at openjdk.org> 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 relaxed the visibility of the actual `Frame`. I guess the `Frame` clone was introduced to have strict visibility in the actual `Frame`. Though this is not needed since the actual `Frame` is in an internal package. Plus, the fact that bug is in the `Frame` class hints in the direction that there should be one `Frame`.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply review feedback on naming in `Masker`
>   
>   `reset` -> `setMask`
>   `initGallopingMask` -> `initVectorMask`
>   `applyGallopingMask` -> `applyVectorMask`

> 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.
> 
> I do not know how effective the long-optimization realy is because/when data is not 8-byte-aligned. But if one wants to implement it, be sure to apply _native_ endianess for the mask-long, the input (eg. via a slice) and the buffer. If one uses the java default big endian (aaargh...), and "happens" to run on a little endian machine, the "optimization" would have to do a byte swap to native endian on read, do the masking and byteswap again on the way out. (same is true when choosing little endian and running on big endian hardware, although i would like the chances there much better ;-))

I don't think alignment is an issue here at all. `ByteBuffer.getLong()` does not have any alignment constraints on the underlying memory. There's no way to know if it is 8-byte aligned afaict. The first 8 bytes (and every subsequent 8 bytes) can be read as a long (subject to this byte ordering issue). The final chunk of up to 7 bytes is then handled byte at a time.

I'm not sure what (if any) difference the platform's native byte order has either for that matter.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24033#issuecomment-2740543533