On Fri, 14 Mar 2025 10:11:29 GMT, Volkan Yazici <vyaz...@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:
>
> Make method name changes backport-friendly
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 ideal ?
The Galloping mask methods, there has to be a more semantically meaningful
name e.g. applyLongMaskRepeating or applyVectorMaskRepeating
(on your horse rather than on yer bike ;-)
I still think the following looking meaningful
public void applyMask(ByteBuffer src, ByteBuffer dst, theMask) {
if (src.order() == dst.order()) {
initLongVectorMask(src, dst, theMask);
applyLongVectorMask(src, dst, theMask);
}
endApplyMask(src, dst, theMask);
}
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24033#issuecomment-2724999193
