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

[Daniel Fuchs]

On Thu, 13 Mar 2025 13:42:40 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:
> 
>   Fix copyright years

src/java.net.http/share/classes/jdk/internal/net/http/websocket/Frame.java line 105:

> 103:          * The source and the destination buffers may be the same instance.
> 104:          */
> 105:         static void mask(ByteBuffer src, ByteBuffer dst, int mask) {

Ok - I'm going to start painting the bikeshed here. Though I like the name `mask`, the fact that there was a method called `mask` before that did something completely different makes me pause. Maybe we should not reuse the name `mask` here, and either keep `transferMasking` or use a new name like `applyMask`. One of my concern is backporting, where `mask` means something else in previous releases. We'd have to remember that in one release it means something and in the next it means something different.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24033#discussion_r1994081856