File: LongFloatConversion.md

package info (click to toggle)
error-prone-java 2.18.0-1
  • links: PTS, VCS
  • area: main
  • in suites: bookworm, forky, sid, trixie
  • size: 23,204 kB
  • sloc: java: 222,992; xml: 1,319; sh: 25; makefile: 7
file content (34 lines) | stat: -rw-r--r-- 1,309 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
A cast from `long` to `float` may lose precision. Prefer an explicit cast to an
implicit conversion if this was intentional.

Consider
[`java.awt.Color`](https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/Color.html)
which has constructors `Color(float r, float g, float b)` and `Color(int r, int
g, int b)`, and the following example:

```java
// Math.round returns a double, which is implicitly converted to float:
new Color(Math.round(18.0), Math.round(0.0), Math.round(18.0));
```

Prefer this (to make existing behavior explicit):

```java
new Color((float) Math.round(18.0), (float) Math.round(0.0), (float) Math.round(18.0));
```

or this (if this implicit conversion to `float` was unintentional):

```java
new Color((int) Math.round(18.0), (int) Math.round(0.0), (int) Math.round(18.0));
```

From [JLS §5.1.2]:

> A widening primitive conversion from `int` to `float`, or from `long` to
> `float`, or from `long` to `double`, may result in loss of precision - that
> is, the result may lose some of the least significant bits of the value. In
> this case, the resulting floating-point value will be a correctly rounded
> version of the integer value, using IEEE 754 round-to-nearest mode

[JLS §5.1.2]: https://docs.oracle.com/javase/specs/jls/se11/html/jls-5.html#jls-5.1.2