So half the complaint here is that Java doesn't let you use the 80-bit x87 floating-point type. Well, actually it does--if you don't add `strictfp` to your method declarations, Java is allowed to compute intermediate results of float and double computations in higher precision, and this was retrofitted because it's actually somewhat difficult to get the x87 floating-point unit to actually do single- or double-precision (as opposed to extended-precision) arithmetic. But you don't actually want to use the 80-bit type; it's slower in practice, and it has some extra wonkiness over other IEEE 754 types that it's really not worth it. And on 64-bit x86, everyone just uses SSE for floating-point units and thus you don't need to worry about x87 unless you explicitly opt into its insanity.

As a numerical analyst, Kahan is pretty obsessed with use-as-much-precision-as-you-can. But there's a useful rule of thumb: you need about twice the amount of working precision as your final result. Since double precision has a 53-bit mantissa (~16 decimal digits), that means if you need only 8 or fewer decimal digits, you're completely fine with double precision. And furthermore, the experiences I've had with many programmers suggest that getting bit-equivalent results from different machines is a higher priority than squeezing the best possible numerics out of your hardware. HPC does tend to care about the latter a lot more, but that's also an area where the solution is almost always to just use your system's advanced math libraries (e.g., MKL for dense linear algebra).