float and Float, double and Double, suffer from arithmetic operational underflow and overflow,
which are tantamount to base 10 range innacuracy.

Consider the cases of Vector3d and Vector3f classes from Java3D, dot and cross product,
that use assumptive, floating point vulnerable implementations,
and need to be corrected somehow:

package javax.vecmath.Vector3d;

//...

public final void cross(Vector3d paramVector3d1, Vector3d paramVector3d2)
{
double d1 = paramVector3d1.y * paramVector3d2.z - paramVector3d1.z * paramVector3d2.y;
double d2 = paramVector3d2.x * paramVector3d1.z - paramVector3d2.z * paramVector3d1.x;
this.z = (paramVector3d1.x * paramVector3d2.y - paramVector3d1.y * paramVector3d2.x);
this.x = d1;
this.y = d2;
}

-How can programmers disable any and or all floating point denormals, on library code
like this that can't be reprogrammed or recompiled everywhere?

Considering

double a = 0.1;
double b = 0.1;
double x = a*b;
out.println(x == 0.01);

-Does anyone know when Java SE will be altered to include something like a runtime
switch that can be included with programs that will prevent woes from situations
like this in absolutely any kind of case?