By WebNest Studio Engineering Team
Java - Core Tutorial
strictfp Keyword in Java
strictfp (short for "strict floating point") is a Java keyword that forces floating-point calculations to follow the IEEE 754 standard precisely and consistently, regardless of the underlying hardware or JVM implementation. Without it, historically, some JVMs were allowed extended intermediate precision for float and double calculations, which meant the exact same Java program could theoretically produce very slightly different floating-point results on different platforms.
Why it matters
strictfp is mostly history now: since Java 17 all floating-point arithmetic is strict by default, and the keyword has no effect. It is still worth recognising in older code and in exam questions. The lasting lesson behind it is that floating-point numbers are approximations, which is why 0.1 + 0.2 is not exactly 0.3.
Watch: Java strictfp Keyword Full Tutorial | Floating-Point Precision Made Simple
Explains what strictfp means, the cross-CPU floating-point problem it solved, IEEE 754 basics, where it is and is not allowed (and why abstract plus strictfp is illegal), how it affects inner classes and subclasses, the Java 17 JEP 306 change, and interview questions.
What strictfp Means
The name is short for "strict floating-point". It was added in Java 1.2 as a modifier you put on a class, interface or method to say: every float and double calculation in here must give exactly the result the IEEE 754 standard defines, bit for bit, on every machine. It never affects int, long or any other integer arithmetic.
The Problem It Solved: Different Results on Different CPUs
Java promises "write once, run anywhere", and that should include the same numbers. The x87 floating-point unit in older Intel processors, however, worked internally with 80-bit registers, wider than a 64-bit double. Forcing every intermediate result back to exact 64-bit double rules on that hardware was slow, so from Java 1.2 the JVM was allowed to keep intermediate results with a wider exponent range. A long calculation, especially one that briefly went past Double.MAX_VALUE or very close to zero, could then produce a slightly different answer on an x87 machine than on other hardware. strictfp was the opt-out: inside a strictfp method, the JVM had to use exact IEEE 754 single and double precision everywhere, so the result was identical on every platform.
IEEE 754 Floating-Point, Explained Simply
IEEE 754 is the international standard for storing and calculating with decimal-point numbers in binary. A double is 64 bits: 1 sign bit, 11 exponent bits and 52 bits of fraction, which gives roughly 15–17 significant decimal digits. A float is 32 bits with about 7 digits. Many decimals, such as 0.1, have no exact binary form, so 0.1 + 0.2 prints 0.30000000000000004 — on every JVM. strictfp never removed that rounding; it only guaranteed that the rounding happened in exactly the same way everywhere. For exact decimal arithmetic such as money, use BigDecimal.
Where strictfp Can Be Applied
strictfp can be applied to a class, an interface, or a method. Applying it to a class or interface makes every method body inside it strict, and that includes its nested and inner classes. It does not pass on to subclasses or to classes that implement a strictfp interface: their own methods follow their own declarations.
strictfp class Calculator { ... }— every method in Calculator, and in classes nested inside it, uses strict floating-point rules.strictfp abstract class Shape { ... }— allowed; the concrete methods in Shape are strict.strictfp interface Scaler { ... }— the interface's own default and static method bodies are strict; implementing classes are not affected.public strictfp double computeArea() { ... }— only this method is constrained.
Where strictfp Is Not Allowed
strictfp describes how a method body computes, so it is only legal where there is a body or a type that contains bodies. The compiler rejects every other placement.
- Variables and fields:
strictfp double x;gives "modifier strictfp not allowed here". - Constructors:
strictfp Point() {}gives the same error. Making the whole class strictfp covers its constructors. - Abstract methods:
strictfp abstract double area();gives "illegal combination of modifiers: abstract and strictfp", because an abstract method has no body for the rule to apply to. The same goes for an abstract method declared in an interface.
Java 17 Change (JEP 306): Always Strict
By Java 17, every processor the JVM supports does floating-point through SSE2 or equivalent instructions, where exact IEEE 754 arithmetic is just as fast as the relaxed mode. JEP 306, "Restore Always-Strict Floating-Point Semantics", therefore made all floating-point operations strict by default — the JVM specification was updated so that strict IEEE 754 semantics apply everywhere, and the strictfp keyword became redundant. It is still legal to write, for backward compatibility, but javac 17 prints warning: [strictfp] as of release 17, all floating-point expressions are evaluated strictly and 'strictfp' is not required. In practice, this means you are unlikely to ever need to type strictfp in code targeting modern Java versions. It remains worth knowing, however, because it still appears in interview questions, certification exams, and in older Java 8/11-era codebases where it was meaningful.
Common Interview Questions
- What is strictfp? A modifier that forces float and double calculations to follow IEEE 754 exactly, so results are the same on every platform.
- When was it introduced? In Java 1.2.
- Where can strictfp be used? On classes (including abstract classes), interfaces and concrete methods.
- Can we use strictfp with abstract methods? No. abstract and strictfp is an illegal combination.
- Can an abstract class be strictfp? Yes.
- Can a variable or constructor be strictfp? No. Both are compile errors.
- Is strictfp inherited by subclasses? No. It applies to the declaring type and its nested types only.
- Is strictfp needed in Java 17+? No. All floating-point is strict by default since JEP 306, and the compiler warns that the keyword is redundant.
Examples
Declaring a strictfp method for guaranteed cross-platform floating-point consistency
public strictfp class PrecisionCalculator {
// Every floating-point operation inside a strictfp class/method
// follows IEEE 754 rules consistently across all JVMs.
public double multiply(double a, double b) {
return a * b;
}
public static void main(String[] args) {
PrecisionCalculator calc = new PrecisionCalculator();
System.out.println(calc.multiply(1.1, 2.2));
}
}
2.4200000000000004
A strictfp class: binary rounding still happens, and an intermediate overflow gives Infinity on every JVM
public strictfp class StrictfpDemo {
static double average(double... values) {
double sum = 0;
for (double v : values) {
sum += v;
}
return sum / values.length;
}
public static void main(String[] args) {
System.out.println(0.1 + 0.2);
System.out.println(average(1.1, 2.2, 3.3));
System.out.println(Double.MAX_VALUE * 2 / 2); // overflows to Infinity under strict rules
System.out.println(Math.ulp(1.0));
}
}
0.30000000000000004
2.1999999999999997
Infinity
2.220446049250313E-16
Common Mistakes
- Assuming strictfp changes the numeric result of a calculation in modern Java — since Java 17, strict behavior is already the default everywhere, so adding the keyword changes nothing.
- Expecting strictfp to fix 0.1 + 0.2 printing 0.30000000000000004 — it only makes rounding consistent, not exact; use BigDecimal for exact decimals.
- Combining strictfp with abstract on a method, which is a compile error because there is no body to make strict.
- Assuming a subclass or an implementing class inherits strictfp from its parent or interface — it does not.
- Trying to apply strictfp to a single local variable or field — it can only be applied at the class, interface, or method level.
- Believing strictfp is needed for basic int/long arithmetic — it only affects floating-point (float/double) computations.
- Confusing strictfp with performance tuning — it is about correctness/consistency of results, not speed.
Exercise
This program prints false, because 0.1 + 0.2 is not stored as exactly 0.3. Change the comparison so that it treats two doubles as equal when they differ by less than a very small tolerance.
Expected output: true
public class FloatCompare {
public static void main(String[] args) {
double sum = 0.1 + 0.2;
System.out.println(sum == 0.3);
}
}
Show hints
- Never compare floating-point results with
==; compare the size of the difference instead. Math.abs(sum - 0.3) < 1e-9is true when the two values are within one billionth of each other.
Show solution
public class FloatCompare {
public static void main(String[] args) {
double sum = 0.1 + 0.2;
System.out.println(Math.abs(sum - 0.3) < 1e-9); // true
}
}
Quick quiz
1. From which Java version is strictfp redundant, because all floating-point arithmetic is strict by default?
- A. Java 17
- B. Java 11
- C. Java 8
- D. Java 21
Show answer
A. Java 17 restored always-strict floating-point semantics, so the keyword no longer changes behaviour.
2. Where could strictfp be applied?
- A. To variables
- B. To classes, interfaces and methods
- C. To constructors only
- D. To packages
Show answer
B. It was a modifier for classes, interfaces and non-abstract methods. It was never allowed on variables or constructors.
3. What does 0.1 + 0.2 == 0.3 evaluate to in Java?
- A. true
- B. false
- C. It does not compile
- D. It depends on the operating system
Show answer
B. 0.1, 0.2 and 0.3 cannot be represented exactly in binary, and the sum differs from 0.3 in the last bits.
Interview questions
What did strictfp do, and is it still needed?
Show answer
It forced floating-point calculations to follow the IEEE 754 standard exactly, so that results were identical on every platform. Without it, older JVMs were allowed to use extra precision on some processors, which could change results slightly. Since Java 17 strict behaviour is always on, so the keyword is accepted but does nothing, and compilers warn that it is unnecessary.
How should you handle money, given that double is imprecise?
Show answer
Do not use double or float for money. Use BigDecimal, created from a String such as new BigDecimal("0.10"), with an explicit rounding mode; or store amounts as whole numbers of the smallest unit, such as paise or cents, in a long.
Key Points to Remember
- strictfp forces IEEE 754-compliant floating-point results consistently across all JVM implementations.
- It was added in Java 1.2 because x87 hardware could keep wider intermediate results, giving slightly different answers across platforms.
- It can be applied to classes, interfaces, and methods (applying it to a class/interface applies it to all its methods and nested types, but not to subclasses).
- It is not allowed on variables, constructors, or abstract methods.
- Since Java 17 (JEP 306), strictfp behavior is the default everywhere and javac warns that the keyword is redundant, making it mostly a legacy/interview topic today.
- It never affects integer arithmetic — only float and double computations.
Practice in the playground
Write and run your own code for this topic, or start from the exercise or an example. Runs plain Java 17. Frameworks such as Spring, and databases, are not available here. Your code for each topic is kept in this browser.
Run the examples
Change an input, predict the result, then compare it with the output. Explain why the result changes.
Written by
WebNest Studio Engineering Team
Practical lessons from developers working with Java, Python, React, databases and production systems.
Led by Vansh Duggal, Founder, WebNest Studio · Full-stack & software engineering