Java strictfp Keyword: Why It Is Obsolete Since Java 17

The strictfp keyword is a modifier that once forced a class, interface or method to compute float and double values with strict IEEE 754 semantics on every platform, and since Java 17 it has no effect. JEP 306 made strict floating-point the only behavior, so all Java code is evaluated as if it were marked strictfp.

We still find strictfp in older libraries, in interview questions, and in the list of Java keywords, where it remains reserved. Knowing what it did helps us read old code and remove the modifier safely.

The following example shows the case strictfp was made for. Doubling the largest double overflows, so halving it again cannot bring the value back.

double max = Double.MAX_VALUE;
double result = max * 2 / 2;            // Infinity on Java 17+, with or without strictfp

Before Java 17, some x87 processors could keep max * 2 in a wider register and return Double.MAX_VALUE instead. We look at that old behavior, why it went away, the syntax rules that still apply, what strictfp never did, and how to clean it out of old code.

1. What strictfp Did Before Java 17

From Java 1.2 to Java 16, the JVM had two floating-point modes. In the default mode, intermediate results could use a wider exponent range than IEEE 754 double allows, which let the x87 floating-point unit of 32-bit Intel CPUs run at full speed. In strictfp code, every intermediate result was rounded to the standard float or double format.

	Default mode (Java 1.2 to 16)	strictfp mode, and all code since Java 17
Intermediate exponent range	Could be wider than double	The IEEE 754 double range
Overflow and underflow	Could be delayed or avoided	Happen at the same point everywhere
Result on different CPUs	Could differ in rare cases	Bit-for-bit identical

The difference appeared only near the limits of the range, such as values close to Double.MAX_VALUE or very small values close to zero. Typical business math gave the same results in both modes, which is why most developers never noticed it.

2. Why strictfp Is Obsolete Since Java 17

Java 17 made strict evaluation mandatory for all floating-point code, so strictfp changes nothing in programs compiled for Java 17 or later. The reason was hardware. Modern x86 CPUs compute with SSE2 instructions, which follow IEEE 754 to the bit at full speed, so the faster default mode no longer had a purpose.

The JLS calls the modifier obsolete and says that it should not be used in new code. The javac compiler of Java 25 warns about every use by default.

Sfp.java:1: warning: [strictfp] as of release 17, all floating-point expressions
are evaluated strictly and 'strictfp' is not required

Code compiled with –release 16 or older still gets the old two-mode rules, but only when it runs on a JVM older than 17. A Java 17 or later JVM evaluates every class file strictly, whatever its version.

3. strictfp Syntax and Rules

The modifier is still legal, so old code compiles unchanged. It can be placed on a class, an interface or a method, and it applies to all code declared inside it, including nested classes.

strictfp class Invoice {
    double total(double net, double taxRate) {
        return net * (1 + taxRate);
    }
}

double total = new Invoice().total(100.0, 0.25);   // 125.0

A few combinations were never allowed, and the compiler still rejects them.

• Variables and fields cannot be strictfp, because the modifier applies to code, not to stored values.
• Constructors cannot carry strictfp, although a constructor inside a strictfp class runs strictly.
• An abstract method cannot be strictfp, because it has no body to evaluate, and javac reports an illegal combination of modifiers.
• An abstract class can be strictfp, and the modifier applies to its concrete methods.

The modifier is not inherited. A subclass of a strictfp class and a class that implements a strictfp interface run in the default mode unless they are marked too, which mattered only before Java 17.

4. What strictfp Does Not Do

Many old tutorials present strictfp as a fix for floating-point surprises, but it never changed rounding. The value 0.1 has no exact binary form, so the classic sum gives the same result with or without the modifier.

double sum = 0.1 + 0.2;                 // 0.30000000000000004
boolean exact = sum == 0.3;             // false
BigDecimal money = new BigDecimal("0.1").add(new BigDecimal("0.2"));   // 0.3

For money and other decimal values, BigDecimal is the correct type. For comparing double values, we compare the difference with a small tolerance instead of using ==.

The modifier also never affected the Math class. Methods such as Math.sin() may use CPU-specific code and can differ in the last bit between platforms. When bit-identical results matter, as in replays of a simulation, StrictMath gives the same result everywhere.

double fast = Math.sin(1e6);           // may differ in the last bit on some JVMs
double portable = StrictMath.sin(1e6);  // -0.34999350217129294

5. Removing strictfp from Old Code

On a project that targets Java 17 or later, deleting strictfp is safe and changes no results. A search for the word finds every use.

When a project must keep the modifier for a while, for example because it still builds a Java 11 release from the same sources, we can silence the warning with -Xlint:-strictfp. Once the oldest supported Java version is 17, the modifier can go.

6. strictfp FAQs

Developers who find strictfp in old code ask these questions.

6.1. Is strictfp deprecated?

The modifier is not formally deprecated, but the JLS calls it obsolete and javac warns about it by default. It stays a reserved keyword, so it cannot be used as a variable or method name.

6.2. Should we use strictfp in Java 21 or Java 25?

No. Since Java 17, every floating-point expression is evaluated strictly, so the modifier adds nothing except a compiler warning.

6.3. Was strictfp added in Java 1.2?

Yes. Java 1.2 introduced the default floating-point mode with a wider exponent range and added strictfp to keep the exact behavior of Java 1.0 and 1.1. Java 17 went back to that original behavior for all code.

6.4. Does strictfp make floating-point results exact?

No. It made results identical on all platforms, not exact. A double still has about 15 to 17 significant decimal digits, and values such as 0.1 are still rounded.

7. Conclusion

The strictfp keyword forced exact IEEE 754 evaluation in a class, interface or method when the JVM allowed a faster mode with a wider exponent range. Since Java 17, all floating-point code is strict, so the modifier has no effect and javac warns about it.

The modifier never fixed rounding errors, which still need BigDecimal or tolerance-based comparison, and it never covered Math, where StrictMath gives portable results. In code that targets Java 17 or later, we remove it.

8. References

• JEP 306, Restore Always-Strict Floating-Point Semantics
• JLS 25, Method Modifiers
• JLS 25, Keywords
• StrictMath (Java SE 25 API)

Happy Learning !!

Source Code on Github