Re: RFR: 8286378: Address possibly lossy conversions in java.base [v2]

2022-05-11 Thread Adam Sotona
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 cast is implied and 
>> possible lossy conversion may silently occur. While similar situations are 
>> resolved as compilation errors for primitive assignments, there are no 
>> similar rules defined for compound assignments."
>> 
>> This PR anticipates the warnings and adds explicit casts to replace the 
>> implicit casts.
>> In most cases, the cast matches the type of the right-hand side to type of 
>> the compound assignment.
>> Since these casts are truncating the value, there might be a different 
>> refactoring that avoids the cast
>> but a direct replacement was chosen here.
>> 
>> (Advise and suggestions will inform similar updates to other OpenJDK 
>> modules).
>
> Roger Riggs has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   remove stray file

I can confirm this patch clears all warnings from java.base.

-

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


Re: RFR: 8286378: Address possibly lossy conversions in java.base [v2]

2022-05-10 Thread Alan Bateman
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 cast is implied and 
>> possible lossy conversion may silently occur. While similar situations are 
>> resolved as compilation errors for primitive assignments, there are no 
>> similar rules defined for compound assignments."
>> 
>> This PR anticipates the warnings and adds explicit casts to replace the 
>> implicit casts.
>> In most cases, the cast matches the type of the right-hand side to type of 
>> the compound assignment.
>> Since these casts are truncating the value, there might be a different 
>> refactoring that avoids the cast
>> but a direct replacement was chosen here.
>> 
>> (Advise and suggestions will inform similar updates to other OpenJDK 
>> modules).
>
> Roger Riggs has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   remove stray file

src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 128:

> 126: // timed poll interrupted so need to adjust timeout
> 127: long adjust = System.nanoTime() - startTime;
> 128: to -= (int)TimeUnit.MILLISECONDS.convert(adjust, 
> TimeUnit.NANOSECONDS);

Can we change this `to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust);` while 
we here?

src/java.base/share/classes/jdk/internal/org/objectweb/asm/Frame.java line 615:

> 613: if (outputStackTop >= elements) {
> 614: outputStackTop -= (short)elements;
> 615: } else {

I think we usually try to avoid changing the ASM code if possible but maybe you 
have to do this because the compiler option is used for compiling java.base?

src/java.base/unix/classes/sun/nio/ch/PollSelectorImpl.java line 123:

> 121: // timed poll interrupted so need to adjust timeout
> 122: long adjust = System.nanoTime() - startTime;
> 123: to -= (int)TimeUnit.MILLISECONDS.convert(adjust, 
> TimeUnit.NANOSECONDS);

This one can also be changed to:

`to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust);`

-

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


Re: RFR: 8286378: Address possibly lossy conversions in java.base [v2]

2022-05-10 Thread Roger Riggs
> 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 occur. While similar situations are 
> resolved as compilation errors for primitive assignments, there are no 
> similar rules defined for compound assignments."
> 
> This PR anticipates the warnings and adds explicit casts to replace the 
> implicit casts.
> In most cases, the cast matches the type of the right-hand side to type of 
> the compound assignment.
> Since these casts are truncating the value, there might be a different 
> refactoring that avoids the cast
> but a direct replacement was chosen here.
> 
> (Advise and suggestions will inform similar updates to other OpenJDK modules).

Roger Riggs has updated the pull request incrementally with one additional 
commit since the last revision:

  remove stray file

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8642/files
  - new: https://git.openjdk.java.net/jdk/pull/8642/files/e72ce85c..7ff806a5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=8642=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8642=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8642.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8642/head:pull/8642

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