RFR: 8286386: Address possibly lossy conversions in java.net.http

[Roger Riggs]

On Wed, 11 May 2022 17:04:19 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/websocket/Frame.java line 222:
>> 
>>> 220:                 // compiler will emit a warning if not cast
>>> 221:                 firstChar &= (char) ~0b10000000_00000000;
>>> 222:             }
>> 
>> Am I right in believing that there was an implicit cast to char here before and the only change is to make it explicit? ie. there is no actual behavior change?
>
> Yes - that's my understanding.

These methods either set or clear a single bit in `firstChar`.
The constant is an `int` so its complement is a 32 bit int.

It could also be written as `~ (char) 0b1000000_0000000`.   Then the 16 bit unsigned char would be complemented.
Either way, the cast is needed to be explicit about the size of the constant.

Another way to avoid the cast would be to define the bit positions as:

`private static final char FIN_BIT = 0b10000000_00000000;
... etc.
`
Then the code in the methods would not need the cast.


    if (value) { 
        firstChar |= FIN_BIT;
    } else {
        firstChar &= ~FIN_BIT;
    }

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

PR: https://git.openjdk.java.net/jdk/pull/8656