Strictfp: Difference between revisions
clarification |
Esmond.pitt (talk | contribs) Not unused, but redundant. |
||
Line 1: | Line 1: | ||
{{lowercase|title=strictfp}} |
{{lowercase|title=strictfp}} |
||
'''strictfp''' is an obsolete and |
'''strictfp''' is an obsolete and redundant reserved word in the [[Java (programming language)|Java programming language]].<ref>{{Cite web|title=Java Language Specification - Chapter 3. Lexical Structure|url=https://docs.oracle.com/javase/specs/jls/se17/html/jls-3.html#jls-ReservedKeyword|url-status=live}}</ref><ref name=":0">{{Cite web|title=JEP 306: Restore Always-Strict Floating-Point Semantics|url=https://openjdk.java.net/jeps/306|url-status=live}}</ref> Previously, this keyword was used as a modifier that restricted [[floating-point]] calculations to [[IEEE 754]] semantics in order to ensure portability. The strictfp keyword was introduced into Java with the [[Java virtual machine]] (JVM) version 1.2 and its functionality was removed in JVM version 17.<ref name=":0">{{Cite web|title=JEP 306: Restore Always-Strict Floating-Point Semantics|url=https://openjdk.java.net/jeps/306|url-status=live}}</ref> As of Java 17, IEEE 754 semantics is required, thus using this keyword has no effect. |
||
==Basis== |
==Basis== |
Revision as of 07:54, 6 August 2023
strictfp is an obsolete and redundant reserved word in the Java programming language.[1][2] Previously, this keyword was used as a modifier that restricted floating-point calculations to IEEE 754 semantics in order to ensure portability. The strictfp keyword was introduced into Java with the Java virtual machine (JVM) version 1.2 and its functionality was removed in JVM version 17.[2] As of Java 17, IEEE 754 semantics is required, thus using this keyword has no effect.
Basis
The IEEE standard IEEE 754 specifies a standard method for both floating-point calculations and storage of floating-point values in various formats,
including single (32-bit, used in Java's float
) or double (64-bit, used in Java's double
) precision.
Some hardware also provides extended precision formats that provide higher precision and/or a larger exponent range. On such architectures it may be more efficient to compute intermediate results using such extended formats. This may avoid round-off errors, overflows and underflows that would otherwise occur, but can cause programs to produce different output on such architectures. It was particularly expensive to avoid the use of extended precision on x86 machines with the traditional x87 floating-point architecture. Although it was easy to control calculation precision, limiting the exponent range for intermediate results required additional costly instructions.
Prior to JVM 1.2, floating-point calculations were required to be strict; that is, all intermediate floating-point results were required to behave as if represented using IEEE single or double precisions. This made it expensive on common x87-based hardware to ensure that overflows would occur where required.
Since JVM 1.2, intermediate computations are, by default, allowed to exceed the standard exponent ranges associated with IEEE 32 bit and 64 bit formats. They may instead be represented as a member of the "extended-exponent" value set. On platforms like x87, overflows and underflows may not occur where expected, producing possibly more meaningful, but less repeatable, results instead.
Since x87 floating point is no longer necessary on x86 processors supporting SSE2, Java 17 again made all floating-point operations strict, effectively restoring the pre-1.2 semantics.[2]
How it works
In the absence of overflow or underflow, there is no difference in results with or without strictfp. If repeatability is essential, the strictfp modifier can be used to ensure that overflow and underflow occurs in the same places on all platforms. Without the strictfp modifier, intermediate results may use a larger exponent range.[3]
The strictfp
modifier accomplishes this by representing all intermediate values as IEEE single precision and double precision values, as occurred in earlier versions of the JVM.[4]
Usage
Programmers can use the modifier strictfp
to ensure that calculations are performed as in the earlier versions; that is, only with IEEE single and double precision types used. Using strictfp guarantees that results of floating-point calculations are identical on all platforms.
It can be used on classes, interfaces and non-abstract methods.[5] When applied to a method, it causes all calculations inside the method to use strict floating-point math. When applied to a class, all calculations inside the class use strict floating-point math. Compile-time constant expressions must always use strict floating-point behavior.[6]
Examples
public strictfp class MyFPclass {
// ... contents of class here ...
}
References
- ^ "Java Language Specification - Chapter 3. Lexical Structure".
{{cite web}}
: CS1 maint: url-status (link) - ^ a b c "JEP 306: Restore Always-Strict Floating-Point Semantics".
{{cite web}}
: CS1 maint: url-status (link) - ^ Gosling, James; Joy, Bill; Steele, Guy L. Jr.; Bracha, Gilad; Buckley, Alex; Smith, Daniel (2017). "4.2.3 Floating-Point Types, Formats, and Values". The Java Language Specification, Java SE 9 Edition. Addison-Wesley Professional. Retrieved 2017-10-06.
- ^ Flanagan, David (March 2005). Java in a Nutshell (Fifth ed.). O'Reilly Media. ISBN 978-0-596-00773-7. Retrieved 2010-03-03.
- ^ Schildt, Herbert (2007). Java: A Beginner's Guide (4 ed.). McGraw-Hill Companies. ISBN 978-0-07-226384-8.
- ^ Gosling, James; Joy, Bill; Steele, Guy L. Jr.; Bracha, Gilad (2005). "15.4 FP-strict Expressions". The Java Language Specification, Third Edition. Addison-Wesley Professional. p. 411. ISBN 0-321-24678-0. Retrieved 2016-03-22.