In Java 19, a long standing bug in Java has been fixed around ensuring the way Float/ Double translates to String. According to the Javadoc, Double.toString(double) should produce a string with a number of digits as small as possible, that still uniquely distinguishes this double from its adjacent double. That was not the case for many doubles. For example, whereas 1e23 and 9.999999999999999E22 are the same double, passing 1e23 to Double.toString(double) was returning "9.999999999999999E22".
For more info refer to https://inside.java/2022/09/23/quality-heads-up/
Unfortunately, this is coming to bite us. In net.sourceforge.pmd.lang.java.ast.ParserCornersTest, under at least testParsersCases17 (haven't checked others yet), we come across one such value: 2.70569498E9, which is equivalent to 2.705695E9. Due to the way the test runs (strict text AST dump comparison vs a recorded baseline), we can't just update the baseline without it breaking the build for prior Java versions.
I still haven't checked the particular use case, but it may be possible to simply choose a different value without such ambiguities. However, this should remain a cautionary tale moving forward.
In Java 19, a long standing bug in Java has been fixed around ensuring the way
Float/Doubletranslates toString. According to the Javadoc,Double.toString(double)should produce a string with a number of digits as small as possible, that still uniquely distinguishes this double from its adjacent double. That was not the case for many doubles. For example, whereas1e23and9.999999999999999E22are the same double, passing1e23toDouble.toString(double)was returning"9.999999999999999E22".For more info refer to https://inside.java/2022/09/23/quality-heads-up/
Unfortunately, this is coming to bite us. In
net.sourceforge.pmd.lang.java.ast.ParserCornersTest, under at leasttestParsersCases17(haven't checked others yet), we come across one such value:2.70569498E9, which is equivalent to2.705695E9. Due to the way the test runs (strict text AST dump comparison vs a recorded baseline), we can't just update the baseline without it breaking the build for prior Java versions.I still haven't checked the particular use case, but it may be possible to simply choose a different value without such ambiguities. However, this should remain a cautionary tale moving forward.