Improvement for Java SE/OpenJDK floating point?

[sminervini.prism]

To core-libs-dev and the Java Comunity Process Team,

It remains the case that I and others need Java floating point and StrictMath (the primary double type
calculator class) to be repaired away from all their denormal and pronormal value possibilities. It has been made
clear by a number of publicly available publication sources, irrespective of age, from their date of publication and
into the future, that with hardware registry additions already present in Java platform hardware, namely SSE versions
and beyond, that repair can and must be wrought for Java float and double numeric types utilised in both Java SE and
OpenJDK's runtime environments. This includes float and double ranges, whenever arithmetic operations at all or certain
method calls involving them are made, where the results manage to straddle the edge of those ranges.

float from 1.40129846432481707e-45 to 3.40282346638528860e+38 (positive or negative).
double from 4.94065645841246544e-324d to 1.79769313486231570e+308d (positive or negative).

The issue is not ascription and reading of possible values in these types, within their ranges. The problem
is with arithmetic operations, +,-,*,/,%,+=,-=,*-,/=,%=, and function calls made upon them that are inside the
StrictMath class, and possibly consequences within any closely bound classes or interfaces, namely those with
Float and Double inside their names.

As we attempted to submit in previous messages to core-libs-dev, IEEE 754 is silent on pertinent matters
around decimal arithmetic, mainly certain end facts about binary and decimal use in computer software;
that they need to have total objectivity at all steps of the way. The proper precedent to draw from,
to inform floating point arithmetic and elementary functions, is not a standard with a small "blind spot",
leading to non sequitur, but two even earlier phenomenon. The first of these states that information and
behaviour can be encoded into a computer, so that such a machine can behave by means of that
information rapidly, consistently, and usefully (therefore meaningfully), to the advantage of humans.

The second fact is that range complete decimal mathematics is for humans, and binary mathematics
is for computers. Therefore, for a decimal result to have proper meaning, it must be entirely correct within
its (rational, truncated) range. The most efficient and only meaningful thing to do to obtain absolutely all
that is to utilise additional (SEE and similar) registers, with appropriate sub-java code, to use all registry
space, including the extra space if needed for decimal/binary range end straddling values, to produce range
accurate Java results via improved operational logic.

It is known that having a little more registry space past the number (result range) limit, for use and
consideration, is the only range, base-10 perfect way to go. It is certainly better than the available
class approaches, which waste memory, speed, and lack important and appropriate auxiliary use options.

In more recent times, it has become the case that there are a number of OpenJDK-downstream Java vendors.
Some of them of suggested to us that the better thing would be for something to be done at the OpenJDK,
JCP level, so that they could follow.

It is also the general observation that FP changes not need not be default only, but that any number of
"switching" approaches are valid; a runtime switch, maybe even keyword additions for various Java code
spaces, data qualifiers, or qualifiers for main methods, Runnables or Threads, could be used to
enable/disable two different floating point operating phenomena, either separately or together. Even
including code that has been compiled already. If determined enough, both modes of floating point
operation could be made compatible on any level, assuaging any concerns there.

Using such an approach, there need be no concerns about a split in Java, or compatability since all
this means that everything remains "under the same roof". An example of is the changes in Java's
switch syntax, to immediate switch on a String, alongside the inclusion of the switch's -> operator.
People later used the simplest, most appropriate approach under their circumstances, updated their
body of learning (which happens within any java release automatically, anyway), kept coding along,
and everybody continued relating and coding sharing or integrating between one another, just as
concordantly as before.

May the Java Community Process reconsider the present floating point operations and method calls
situation, based on an imperfect standard and improper workaround, and provide corrected,
defaulting or even specifying-compatible, code compatible ways for Java floating point arithmetic and
Calculator class method results to always cohere in their ranges, without any denormal and pronormalvalue inclusions at all?

Sent with [ProtonMail](https://protonmail.com/) secure email.