I am after a group of what could be terms 'Java SubSystem developers' to alter and rebuild three versions of the Java runtime to address the following issues:
In the Java OpenJDK 12, floating point denormal and pronormal values result from arithmetic operations on float and double, Float and Double. The means of the floating point operations could be enhanced or replaced and rendered range accurate for the value results last decimal place. This all corresponds to the defaulting mode where the strictfp keyword is absent (strctfp mode should be left unchanged).
What I believe I am after is the floating point operations behaviour 'modes' that Java 1.1 used to have. Maybe it will be enough, largely, to copy from those old instrinsics again, although what I am after is a change to 64 bit Java, not 32 bit.
I presently seek that Windows 64 bit, Linux 64 bit and Mac 64 bit runtimes be changed. It is my understanding that once the intrinsics involved are done for one OS version, it can be 'pasted over' and rebuilt into the other OS versions.
I would like these floating point runtime alterations to be on a runtime 'done both ways': I want both a distinct runtime and a joint compiler/runtime file group for each OS platform. If not, the joint compiler and runtime kit approach can be kept together, the 'javac' and 'java' / 'javaw' commands. I would, in this regards, where posible, hope for both of these options.
Direct mode arithmetic on float, double, Float, Double, alongside the version of scientific or engineering notation that can commence to be used inside these types, as well as hexadecimal mode arithmetic, accessible via '0x', likely all need updating, to keep the least decimal place correct under floating point denormal and pronormal circumstances. The related operations will be:
+, -, *, /, %, ++x , --x, x++, x--, (, ), +=, -=, *=, /=, %=.
Operand order and bracket involvement may also be part of what has to be repairs.
java.lang.StrictMath will need to be updated so that all its method calls operate with full accurate performance for the values final decimal place via all function input values. If any of StrictMath contains the strictfp keyword, those will have have to be removed and compiled out, as might be needed with inside java.lang.Math.
I am not quite sure where they presently keep the source code, resource files, and build script(s) for OpenJDK 12, yet I believe they are publically available.
It is my hope that the updated results, possessing range accurate arithmetic operations, will load and accumulate in memory systematically, so that the relevant sub operations arrange well in memory, scale well with many such java (program level) operations, and that while the total result will be slower than floating point mode, things will continue to execute quite fast enough.
In keeping with the GPL license, the source code and resource files, as well as the built product, should be uploaded to Sourceforge or very similar. Everyone involved with the development can attach their names to the project online as they wish.
**It would be very helpful if individual(s) involved can align to a GMT + 10:30 timezone and are able to, during any particularly day, take part in continuing time-aligned discussions by email. Live chats and Skyping are not really an option given other restrictions involved that can't presently be got around.
I envisage a situation where the successful applicant will not wait to the end of the postage time period for this Job task, but will be notified, email exchanged with, and commence their task as promptly as becomes feasible, using their time before deadline throughout.
About the recuiterMember since May 20, 2018 Wilda Satya Per
from Dagestan, Russia