Active Reply to Java Serious Bug Problem?
PowerUser1234 opened this issue · comments
I have submitted the latest about the serious bug issue that we need active addressal for in the latest
version of the OpenJDK. We have submitted the specification document for our recommended fix
to
https://groups.google.com/g/ojdkbuild/c/PpN7rSN9u20
Can someone please type a reply to us, without just closing the issue with no response? It is the case that
default change is not necessary, and that a separate patch program approach is a possibility, to allow
for the choice of compatibility to the Java ecosystem. At any rate, can someone please type an English reply
here, or email me back at
?
I checked your attachment there. You seem to confuse OpenJDK, where that issue could be addressed, with ojdkbuild which provides packages that do not intend to deviate in behavior from upstream OpenJDK in this regard. You'd best reach out through channels from here: https://openjdk.org/
I'd recommend plain text mail (no HTML) without attachments as well.
I have tried to address this in the attachment file I sent with a second messages to the ojdkbuild google group. Can you please consider the following:
Java JDK/JRE Java runtimes generate floating point arithmetic or java.lang.StrictMath overflow and underflow errors within values as a result of Java source code like this, either in the defaulting base 10 mode, but also when hexadecimal notation for base 16 numbers starts to be used, which is denoted with a 0x inside float and double, the two Java homes of floating point. These are presently all logic error phenomena within the language which can and aught be fixed at the level of the language vendor.
Oracle and the Java Community process have not apprehended repeated bug requests on their bugs system, and have chosen not to act further despite multiple discussion attempts about the reasons and needs involved, on their relevant public email lists. While it would be most appropriate for the most upstream vendor to implement these corrections, in face of a total refusal, the best remaining option for corrections that should, must, happen is to inquire of other vendors.
Error workarounds are used to try to cover floating point errors, being BigInteger, BigDecimal, and the big-math function library and similar, in Java. They introduce an entire tier to Java software which isn't needed. BigInteger and BigDecimal are slow and produce a loss in speed, are larger in RAM and waste memory, and don't allow the use of arithmetic operator source code syntax. To say nothing about the absence of an included data accurate type calculator class. But BigInteger and BigDecimal only work outside classes or interfaces; if the internals of library classes or interfaces are written naively, or in any floating point error vulnerable fashion, and cannot be decompiled and are source code inaccessible, or are bound with other (unknown) computer language(s) in that state of affairs which won't be changing in the context, you are stuck with value errors being able to occur and corrupt the software. Things that developers and their programs always need good and better solutions for.
Floating Point correction, in its most commensurate manner in relation to where the OpenJDK is right now (2022), can't be done with total compatibility, but can be done with majority compatability without its present errors. The entire change set per one version of Java can be contained in a separate, optional installation patch. There can be a floating point mode on/off switch for the runtime, classes, interfaces, fields, methods and operators with data, the only way to make floating point types and values range accurate without changing or removing the IEEE 754 equation binary mapping scheme is to augment or lengthen the 32 bit or 64 bit array, by some unknown and varying amount. The impacts of that in the Java language in hardware, but particularly the associated default Java libraries, are simply too huge to justify, along with departing from 32 and 64 bits in strict terms. The only other alternative is to adjust the curve equation and the binary to decimal and hexadecimal mappings Java uses for floating point storage and arithmetic evaluation to floating point storage.
Is ojdk build prepared to consider these matters and approach doing something to changing things systematically to change OpenJDK Java's floating point errors?
While it would be most appropriate for the most upstream vendor to implement these corrections, in face of a total refusal, the best remaining option for corrections that should, must, happen is to inquire of other vendors.
Apparently this project is dead so I wouldn't expect anything here. Have you considered providing your own OpenJDK builds with this issue resolved?