Most versions of Java SE have issues with floating point arithmetic.
They can gain underflow and overflow artifacts, which are aside from an accuracy answer.
double a = 0.1;
double b = 0.1;
double x = a*b;
out.println()x == 0.01); //false.
There needs to be an option to disable the defaulting mode float point implementation,
so that floating point implementation and overflow/underflow with double, float, Double, Float,
simply does not occur. If it is a compiler or runtime option, then there should be a control
panel location or similar so that the setting can be submitted once for all programs.
Java's floating point semantics are very clearly prescribed in the Java Language Specification (which includes rounding rules), and the OpenJ9 technology dutifully adheres to the specification. Modifying any of those rules, simply put, would not make OpenJ9 a Java-compliant implementation. The OpenJ9 technology is highly optimized to adhere to the specification and supporting alternate floating point semantics may impact the performance and quality that OpenJ9 consumers, developers, and researchers expect. Therefore, any option to alter those semantics will not be committed into this project.
Perhaps if you could describe what you're hoping to achieve by altering the rounding rules we could recommend a solution that fits within the rules of the JLS. For example, if you're concerned that the representation of floating point numbers is leading to unacceptable rounding errors then perhaps the BigDecimal class is a better fit for your computations. More details on your circumstances would help formulate a recommendation.
If you're concerned that the Java language itself is remiss in not supporting more flexible floating point semantics then this is not the right forum to report that. Rather, I encourage you to submit a Java Specification Request (JSR) as part of the Java Community Process (at https://jcp.org) to describe your proposal, motivations, and expected outcome. This will be reviewed and evaluated by the Java community. That is the proper procedure for influencing changes in the Java language itself, and should they be accepted the OpenJ9 project will implement them as any compliant JVM would.
Details of Java's floating point specification: https://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.2.3
Question answered
Most helpful comment
Java's floating point semantics are very clearly prescribed in the Java Language Specification (which includes rounding rules), and the OpenJ9 technology dutifully adheres to the specification. Modifying any of those rules, simply put, would not make OpenJ9 a Java-compliant implementation. The OpenJ9 technology is highly optimized to adhere to the specification and supporting alternate floating point semantics may impact the performance and quality that OpenJ9 consumers, developers, and researchers expect. Therefore, any option to alter those semantics will not be committed into this project.
Perhaps if you could describe what you're hoping to achieve by altering the rounding rules we could recommend a solution that fits within the rules of the JLS. For example, if you're concerned that the representation of floating point numbers is leading to unacceptable rounding errors then perhaps the BigDecimal class is a better fit for your computations. More details on your circumstances would help formulate a recommendation.
If you're concerned that the Java language itself is remiss in not supporting more flexible floating point semantics then this is not the right forum to report that. Rather, I encourage you to submit a Java Specification Request (JSR) as part of the Java Community Process (at https://jcp.org) to describe your proposal, motivations, and expected outcome. This will be reviewed and evaluated by the Java community. That is the proper procedure for influencing changes in the Java language itself, and should they be accepted the OpenJ9 project will implement them as any compliant JVM would.