OpenJDK or SE Java Floating Point Options?

[sminervini.prism]

To core-libs-dev, and Glavo,

this inner nature of C++, simply means that the floating point equation can be altered in the decimal
direction; the beginning of value degredation could be altered in the equation to be entirely outside
number type's the range.  C++'s "apparent floating point" and SSE, and SSE descendents, are still a
solution to look for which I suggest to OpenJDK and JCP.

It is still the case that I and others need Java floating point and StrictMath
(the key double type calculator class) to be repaired of their denormal and pronormal errors and the circumstances
creating such. Such repair is possible, using an SSE oriented approach, while maintaining the current ranges of
float and double.

Their ranges seem to be:

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

As I attempted to submit in my previous  message to core-libs-dev, IEEE 754 is silent on pertinent matters
around floating point arithmetic, mainly certain end facts concluding binary and decimal
use in computer software; the need to have range objectivity. The proper precedent to draw from is not a
standard with a small "blind spot", due to reciprocal exponential terms alone, but the phenomenon which
simply states that both information and behaviour can be encoded into a computer, so that such a machine
will behave by means of that information rapidly, consistently, and usefully (therefore meaningfully),
to the advantage of humans.

Range any decimal mathematics, including floating point, should be for humans, and binary
mathematics is for computers. Therefore, for any decimal result to have proper meaning,
it must be entirely correct within its (rational, truncated) range. The most meaningfull thing
to do, while creating the least number of language disturbances,  is to utilise
additional (SEE and similar) registers, with appropriate sub-java (implementation) code, to use all registry
space, including the extra space if needed, 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. It is also the case
that asymptotic number generation from the floating point equation that Java uses can be offset
to occur outside of the end point of the decimal values range end.

May the Java Community Process reconsider the present floating point operations and method calls
situation, based on an imperfect standard and improper operation improper and workarounds, and
provide corrected, defaulting or specified compatible ways for Java floating point arithmetic and
Calculator class method results to always cohere in their ranges, without denormal and pronormal
inclusions whatsoever?