RFR: 8261669: Add lint warning for widening primitive conversions that lose information

Raffaello Giulietti rgiulietti at openjdk.org
Fri Feb 21 11:33:52 UTC 2025


On Thu, 20 Feb 2025 20:57:47 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR is a prototype to stimulate discussion of [JDK-8261669](https://bugs.openjdk.org/browse/JDK-8261669), which seeks to add more warnings when an implicit cast of a primitive value might lose information. This can possibly happen when converting an `int` to `float`, or when converting a `long` to `float` or `double`. Java does not require an explicit cast for such assignments, even though they may result in information loss.
> 
> I'm interested in feedback both on whether this is a good idea and also the approach taken - thanks!
> 
> Currently, we generate this warning, but only for assignment operators, e.g.:
> 
> int x = 0;
> x += 1.0f;   // warning here
> 
> 
> This PR would add warnings for two additional cases, (a) regular assignments and (b) method parameters, e.g.:
> 
> void method(float f) { }
> ...
> float a = 0x10000001;   // warning here
> method(0x10000001);     // warning here
> 
> 
> It would _not_ generate a warning in cases (a) and (b) when the value is a constant value and we can determine that no information would be lost, e.g.:
> 
> float f1 = 0x10000000;     // no warning here
> 
> The definition of "no information would be lost" is that a round trip results in the same value, e.g., `(int)(float)x == x`. In the examples above, `0x10000000` survives the round trip but `0x10000001` does not.
> 
> As usual, warnings can be suppressed via `@SuppressWarnings` or by adding an explicit cast:
> 
> 
> float a = (float)0x10000001;   // no warning here

The "roundtrip technique" is not always sufficient.
For example, `(int) (float) Integer.MAX_VALUE == Integer.MAX_VALUE` evaluates to `true`, despite `Integer.MAX_VALUE)` not being exactly representable by `float`.

You may want to take a look at `java.lang.runtime.ExactConversionsSupport`.

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

PR Comment: https://git.openjdk.org/jdk/pull/23718#issuecomment-2674307463


More information about the build-dev mailing list