The output on lines 26 and 29 is the same (see the code comments on lines 6, 7, 15, and 16 to see the effects that the hightest e+number has on that output).
Since the output is the same, I don't see what strictfp double method does differently than the regular double method. What am I missing?
I think the OP's question is, why is there not a difference when we don't use strictfp? He's comparing code with strictfp, to code without strictfp, and finds that they give the same result. And the main reason for that is: the only guarantee made for strictfp is what happens when you do have strictfp. There isn't any guarantee for what happens when you don't have it. Some systems may behave exactly the same as for strictfp, and some may behave differently. There's nothing wrong with that, and it's not really something worth worrying about.
Mike Simmons wrote:I think the OP's question is, why is there not a difference when we don't use strictfp?
So perhaps that could be answered to OP in a more primite way, that's because OP's system implementation is so to speak a typical. As in JLS and Wikipedia articles mention, some systems may produce difference as a result of differently achieved floating point arithmethics.
So having strictfp modifier, it ensures, that floating point arithmetics are done following strictly defined standard IEEE Standard for Floating-Point Arithmetic (IEEE 754). So once again, OP's system follows that as a default, hence no difference either way.
But the only differences you are likely to notice even if there is a difference between strictfp and ordinary floating‑point aritthmetic are those differences causing overflow or underflow. Only when here is an intermediate calculation result with an absolute value > Double#MAX_VALUE or < Double#MIN_VALUE. None of the calculations shown produces results outwith the defined range of a double, so there will be no differences observable.
I have only ever used strictfp to see whether it works, and I haev never perceived a difference anyway.
But strictfp isn't a “beginning” subject: moving discussion.
So I saw that strictfp is becoming the default for Java SE 17, and got all hot and bothered for a minute before being reminded that this will generally make no difference on any modern hardware:
The only place in practice that you really saw different behaviors was on Intel processors using classical x87 type instructions, which apparently basically never happens anymore.
So you would never see a difference on any places you were going to run Java 17 anyway, if I am not confused.
Logically, we might think this means "get rid of strictfp" but Java doesn't do that.
Instead, tons of documentation gets simpler (JLS and JVM) by just calling everything strictfp by default.
I think this is unlikely to make any difference anywhere except the Java cert exams have one less keyword to ask questions about?
I am just kidding, it has probably been years since they had strictfp questions. I do own some VERY old Java books, including 1.4 Cert Prep (hand-me-downs, I never took the exams).
There really aren't that many keywords, so removing one from the pool of what we would ever have a reason to use seems like a minor big deal.
RTFJD (the JavaDocs are your friends!) If you haven't read them in a long time, then RRTFJD (they might have changed!)