On Tue, 10 May 2022 23:01:33 GMT, Roger Riggs wrote:
>> PR#8599 8244681: proposes to add compiler warnings for possible lossy
>> conversions
>> From the CSR:
>>
>> "If the type of the right-hand operand of a compound assignment is not
>> assignment compatible with the type of the variable, a c
On Tue, 10 May 2022 13:51:37 GMT, Jaikiran Pai wrote:
>> This change proposes to implement the enhancement noted in
>> https://bugs.openjdk.java.net/browse/JDK-8209137.
>>
>> The change introduces a new API to allow applications to build a
>> `java.net.http.HTTPClient` configured with a specif
On Wed, 11 May 2022 08:12:12 GMT, Michael McMahon wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix javadoc link in test
>
> src/java.net.http/share/classes/java/net/http/HttpClient.java line 378:
>
>> 376:
On Wed, 11 May 2022 08:54:48 GMT, Jaikiran Pai wrote:
>> src/java.net.http/share/classes/java/net/http/HttpClient.java line 378:
>>
>>> 376: *
>>> 377: * @implSpec The default implementation of this method throws
>>> 378: * {@code UnsupportedOperationException}. {@code
On Wed, 11 May 2022 11:34:33 GMT, Michael McMahon wrote:
>> Hello Michael,
>> Most users will be using the `HttpClient.newBuilder()` to create the
>> builder, so this note about `UnsupportedOperationException` can be
>> confusing. However, for implementations (libraries?) which provide their
On Tue, 10 May 2022 13:51:37 GMT, Jaikiran Pai wrote:
>> This change proposes to implement the enhancement noted in
>> https://bugs.openjdk.java.net/browse/JDK-8209137.
>>
>> The change introduces a new API to allow applications to build a
>> `java.net.http.HTTPClient` configured with a specif
In relation to [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681),
please find here a patch that addresses possibly lossy conversions in
java.net.http
-
Commit messages:
- Fix comments
- 8286386: Address possibly lossy conversions in java.net.http
Changes: https://gi
On Wed, 11 May 2022 15:42:25 GMT, Daniel Fuchs wrote:
> In relation to
> [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find
> here a patch that addresses possibly lossy conversions in java.net.http
@pavelrappo I would appreciate if you could review these changes
> PR#8599 8244681: proposes to add compiler warnings for possible lossy
> conversions
> From the CSR:
>
> "If the type of the right-hand operand of a compound assignment is not
> assignment compatible with the type of the variable, a cast is implied and
> possible lossy conversion may silently
On Wed, 11 May 2022 15:42:25 GMT, Daniel Fuchs wrote:
> In relation to
> [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find
> here a patch that addresses possibly lossy conversions in java.net.http
src/java.net.http/share/classes/jdk/internal/net/http/hpack/QuickHuffm
On Wed, 11 May 2022 16:55:16 GMT, Michael McMahon wrote:
>> In relation to
>> [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find
>> here a patch that addresses possibly lossy conversions in java.net.http
>
> src/java.net.http/share/classes/jdk/internal/net/http/websock
On Wed, 11 May 2022 16:30:41 GMT, Roger Riggs wrote:
>> PR#8599 8244681: proposes to add compiler warnings for possible lossy
>> conversions
>> From the CSR:
>>
>> "If the type of the right-hand operand of a compound assignment is not
>> assignment compatible with the type of the variable, a c
On Wed, 11 May 2022 16:52:07 GMT, Michael McMahon wrote:
>> In relation to
>> [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find
>> here a patch that addresses possibly lossy conversions in java.net.http
>
> src/java.net.http/share/classes/jdk/internal/net/http/hpack/Q
On Wed, 11 May 2022 17:04:19 GMT, Daniel Fuchs 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) ~0b1000_;
>>> 222:
On Wed, 11 May 2022 17:37:44 GMT, Roger Riggs wrote:
>> 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) 0b100_000`. Then the 16 bit
On Wed, 11 May 2022 17:46:15 GMT, Daniel Fuchs wrote:
>> 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) 0b100_000`. Then the 16 bit
>> unsigned char would be comp
> In relation to
> [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find
> here a patch that addresses possibly lossy conversions in java.net.http
Daniel Fuchs has updated the pull request incrementally with one additional
commit since the last revision:
Use char const
On Wed, 11 May 2022 18:02:32 GMT, Daniel Fuchs wrote:
>> In relation to
>> [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find
>> here a patch that addresses possibly lossy conversions in java.net.http
>
> Daniel Fuchs has updated the pull request incrementally with one
On Wed, 11 May 2022 17:49:28 GMT, Roger Riggs wrote:
>> Ah! Good point. Maybe I should use a constant and get rid of the cast.
>
> 👍 I'd put `_MASK` in the name along with whatever name is used for the bits
> in the frame spec .
Done
-
PR: https://git.openjdk.java.net/jdk/pull/865
> In relation to
> [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find
> here a patch that addresses possibly lossy conversions in java.net.http
Daniel Fuchs has updated the pull request incrementally with one additional
commit since the last revision:
Add _MASK suff
On Wed, 11 May 2022 17:49:28 GMT, Roger Riggs wrote:
>> Ah! Good point. Maybe I should use a constant and get rid of the cast.
>
> 👍 I'd put `_MASK` in the name along with whatever name is used for the bits
> in the frame spec .
@RogerRiggs Actually - I'm no longer sure that this will work:
j
On Wed, 11 May 2022 18:23:30 GMT, Daniel Fuchs wrote:
>> 👍 I'd put `_MASK` in the name along with whatever name is used for the bits
>> in the frame spec .
>
> @RogerRiggs Actually - I'm no longer sure that this will work:
>
>
> jshell> char x = 0b1000_
> x ==> '耀'
>
> jshell> var
> In relation to
> [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find
> here a patch that addresses possibly lossy conversions in java.net.http
Daniel Fuchs has updated the pull request incrementally with one additional
commit since the last revision:
Revert adding
On Wed, 11 May 2022 18:25:00 GMT, Daniel Fuchs wrote:
>> @RogerRiggs Actually - I'm no longer sure that this will work:
>>
>>
>> jshell> char x = 0b1000_
>> x ==> '耀'
>>
>> jshell> var y = ~x
>> y ==> -32769
>>
>> jshell> char y = ~x
>> | Error:
>> | incompatible types: possible
> In relation to
> [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find
> here a patch that addresses possibly lossy conversions in java.net.http
Daniel Fuchs has updated the pull request incrementally with one additional
commit since the last revision:
Revert adding
On Wed, 11 May 2022 18:33:44 GMT, Daniel Fuchs wrote:
>> So if x is a char, ~x seems to be an int :-(
>
> I have reverted adding constant fields. Too bad - the casts are back.
Phooey: Sorry to have lead you astray. :(
And casting before `~` does the same not wanted result.
-
PR:
On Wed, 11 May 2022 16:30:41 GMT, Roger Riggs wrote:
>> PR#8599 8244681: proposes to add compiler warnings for possible lossy
>> conversions
>> From the CSR:
>>
>> "If the type of the right-hand operand of a compound assignment is not
>> assignment compatible with the type of the variable, a c
On Wed, 11 May 2022 17:10:45 GMT, Daniel Fuchs wrote:
>> src/java.net.http/share/classes/jdk/internal/net/http/hpack/QuickHuffman.java
>> line 739:
>>
>>> 737: buffer |= (codeValueOf(c) >>> bufferLen); //
>>> append
>>> 738: bufferLen += (int) le
On Mon, 9 May 2022 23:15:40 GMT, Bradford Wetmore wrote:
>> Hi,
>>
>> I need a review of this fix to allow a read-only 'src' buffer to be used
>> with SSLEngine.unwrap(). A temporary read-write buffer is created in the
>> SSLCipher operation when a read-only buffer is passed. If the 'src' is
On Mon, 9 May 2022 23:48:24 GMT, Bradford Wetmore wrote:
>> Hi,
>>
>> I need a review of this fix to allow a read-only 'src' buffer to be used
>> with SSLEngine.unwrap(). A temporary read-write buffer is created in the
>> SSLCipher operation when a read-only buffer is passed. If the 'src' is
On Wed, 11 May 2022 05:52:38 GMT, Xue-Lei Andrew Fan wrote:
>> Hi,
>>
>> I need a review of this fix to allow a read-only 'src' buffer to be used
>> with SSLEngine.unwrap(). A temporary read-write buffer is created in the
>> SSLCipher operation when a read-only buffer is passed. If the 'src' i
On Wed, 11 May 2022 00:31:23 GMT, Bradford Wetmore wrote:
>> Hi,
>>
>> I need a review of this fix to allow a read-only 'src' buffer to be used
>> with SSLEngine.unwrap(). A temporary read-write buffer is created in the
>> SSLCipher operation when a read-only buffer is passed. If the 'src' is
On Wed, 11 May 2022 22:49:02 GMT, Anthony Scarpino
wrote:
>> src/java.base/share/classes/javax/net/ssl/SSLEngine.java line 677:
>>
>>> 675: * @see #unwrap(ByteBuffer, ByteBuffer[], int, int)
>>> 676: *
>>> 677: * @implNote The data in {@code src} may be modified during the
>
33 matches
Mail list logo