By using AWS re:Post, you agree to the Terms of Use

Java Floating Point Correction Patch in Corretto in a Compatible Manner.


Dear Corretto,

This email is in regards to, which is closed at this time.

I/we are not in a position to just leave this particular subject where last left, and we don't want the discussion or apprehension of this subject to remain closed.

As we tried to describe on the beginning of our thread at ,

Java floating point denormal and pronormal values, from arithmetic and StrictMath function calls, in terms of range accuracy, don't correspond to decimal or binary mathematics. Because they are not one or the other, they don't correspond to anything. IEEE 754, for these reasons, is incomplete, and trying to justify Java's present state due to IEEE 754 is a non sequitar, as is, more importantly, the present floating point state of OpenJDK, and Corretto, at least right now.

-If just to start, how could correcting Java's default floating point behaviour possibly break compatibility? What on earth could correcting the present, strange, erroneous and inconsistent behaviour of Java floating point as it is now, possibly break compatibility with? We can't really see or think of one example, certainly one that is good for Java, and not a lower level language. Forgive our naïveté, but are there really any such real useful examples, such, at all, pertinent to a Java space, needing floating point errors without their base 10 range correction?!?!

-Even this is not the main thrust of our request. Our request submission to Coretto still is for the sake of the implementation and release of a Coretto Java patch to itself. A patch can be included or omitted, installed or not, still allowing compatibility. But even with the inclusion of a patch, various switches or options for the runtime could be involved, to enable a changed floating point arithmetic or StrictMath, yet still allowing compatability, either totally, or in some desired partial or co-integral manner, which could still succeed in being previously compatible, if one pauses to think. :)

We can't exactly allow for this discussion to be just halted, because we in fact are beginning to NEED corrected OpenJDK floating point arithmetic, and an equivalent corrected StrictMath, because of the 2D graphics and 3D visual graphics work we are now planning. The present workarounds are too slow, and waste too much memory. We need continuous float and double range accuracy and the other facilities of those earlier types. As will a large number of programmers or companies out there, who haven't come forward, or persisted.

Can those involved at Corretto reconsider this matter, and implement and release a base 10 floating point arithmetic and StrictMath correction or mode varying patch for Corretto Java, for present and future versions, for its JDK and JRE, on all offered Correto platforms, now and into the future?

asked 4 months ago16 views
1 Answers


Thank you for reaching out to us.

The proposed request is a specific change in Java and needs to be discussed with the OpenJDK community. Any changes to OpenJDK as a result of that discussion will be included in Corretto but Corretto can't differ from the Java spec.

answered 4 months ago
  • The issue of floating point errors has been raised repeatedly, before, with the JCP.

    Because of this, I am trying to approach Corretto Java to do what they alone could do, which is to implement floating point correction inside one of their patches for their Corretto Java. Can what I am submitting still be considered and taken on board? Why exactly can't Corretto issue a patch, at least, that differs from the spec, particularly in a bug area, and an incomplete area in the set of Java standards, a "blind spot"? Particularly since a patch can always be seen as optional, anyway?

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions