Compatible Updating of Java SE, OpenJDK floating Point?

[sminervini.prism]

To Oracle, OpenJDK and the Java Community Process,

use of the floating point arithmetic formula

(-1)^s × m × 2^(e - 127)

for both float and double, while adhering to IEEE 754 statements, and nothing else,
means that there is an accuracy degredation that does occur in the position of the right
most decimal digit. The 754 standard does nothing to exactly address this degredation.

This occurs in float and double data and variables, from direct source code, and indirect pre-compiled code that has been compiled already, but can't be altered. By means of arithmetic operators, and StrictMath method calls.

It has gotten to the point where the accuracy workarounds using BigInteger, BigDecimal,
or the big-math library for an accurate type calculator class, is all both all too slow and too large in memory, where they really can be avoided, which is for most cases.

32 and 64 bit registers for float and double, nowadays, have additional "SSE" bits, which means thata small amount more writing and consideration can be done so that degredation happens entirely outside the present ranges for float and double, which are:

float: 4 bytes, IEEE 754. Covers a range from 1.40129846432481707e-45 to 3.40282346638528860e+38 (positive or negative).

double: 8 bytes IEEE 754. Covers a range from 4.94065645841246544e-324d to 1.79769313486231570e+308d (positive or negative).

In order to correct the digit accuracy degredation phenomenon, either the default mode should be changed, since there is no coherent way to need or rely on an innaccurate final decimal digit, or a compatability mode should be brought in so that either mode of floating point type arithmetic or StrictMath method call can be used, both for original code and re-used library code.

Even without recompiling, of course floating point errors can be changed, and compatibly. Runtime or better, compile time switches can be introduced. Key words could be introduced that may apply at many different levels, for compiled code or source code. Method calls to a new overhead Factory type class would be an approach. Maybe even annotations could be used for the compiler, which can already apply at any point that floating point arithmetic and StrictMath methods and fields may occur, if such an approach doesn't include too many inneficiencies. There might be ways to acheive this be either appending to how Java compiles, or not.

Whevever there is a code instance in a space, there could be an annotation
or a keyword. At the class or interface or static block level. At the
variable, data, field and method level. Even at the main method,
Thread level, Runnable or Future level, or even further. Data in variables or
same type objects can always be re-read, and changed.

Something similar did take place when the new version of the Java switch statement came in. It allowed String to be immediately switched on. Instead of just end result coelesce, it also allows for cases to be coelesced, with a new operator, the -> operator. There was no split in Java, and programmers using either approach within logical bounds has never lead to any problem. The same is a parallel and true for enhancement of Floating Point use.

SSE and similar post registry bits seem to be the key to such. Is it possible for the OpenJDK to actively apply floating point arithmetic and StrictMath method result correction to its release versions of its JDK and JRE?