IEE 754 doesn't specifically say anything about the base 10 digit degradation that can happen at the right hand side of
float and double, inside their information range. 754 is not complete, and is not enough as justification. However all examples
like that are logic errors, that need to be repaired in either a default or mutual way, simply because denary accuracy is required
from them and out of the compiled Java program, and for any further in the program itself.
The problems occur by means of java arithmetic operations on float and double, and the java.lang.StrictMath method calls
as well. Any of these operators, on those two types, are presently offenders:
+, -, *, /, %, ++n, --n, n++, n--, +=, -=, *=, /=, %=
The workarounds, being BigInteger, BigDecimal, big-math are too slow and too large in memory, and don't allow for the use
of arithmetic operators. Things that we need!
Oracle and the Java Community Process aren't responding at all on this issue. It is better that a downstream vendor
accomplish these things, in a default or "switch" controlled mutually compatible way, rather than logic errors remain in the
Java runtime, requiring a poorer workaround to evade an error, permanently, for the whole Java language into the future.
The other option is a version compatible patch for one vendor's JDK and JRE that can be included or omitted.
Some entity out there that publishes an official implementation of OpenJDK simply must correct this whole problem,
even withstanding Oracle and JCP ignoring these problems.
Considering all this new information, can Temurin or
Adoptium change their minds on this critical issue?
Yours Sincerely,
Sergio Minervini
S.M.