Posted by ZacharyABCD on May 23, 2018; 7:18am
URL: https://forum.jogamp.org/Java3D-and-Floating-Point-tp4038882.html

Classes and methods that are like

javax.vecmath.Vector3f.cross(Vector3f v1, Vector3f v2)
javax.vecmath.Vector3d.cross(Vector3d v1, Vector3d v2)

can produce (ranged) innacurate, overflow or underflow
results in float and double return values, if the data for
the input vectors are in just the vulnerable but unavoidable
places.

-Is it possible that the logic for methods like this will be redone,
either just where things presently stand in Java, or ever as a
result of numeric value types that emerge with Project Valhalla?

-It is possible that JEP 306 would go ahead, eliminating any
such problem in the calculations of methods like these two examples?

https://bugs.openjdk.java.net/browse/JDK-8175916