JDK-8062163 : java/awt/geom/AffineTransform/TestInvertMethods.java test fails
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-10-27
  • Updated: 2015-06-04
  • Resolved: 2014-11-06
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
9 b42Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
java version "1.9.0-ea-fastdebug"
Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b36)
Java HotSpot(TM) Client VM (build 1.9.0-ea-b36, mixed mode)

This is caused by https://bugs.openjdk.java.net/browse/JDK-4477961 : java.lang.Math.toDegrees(double) could be optimized which was fixed in b33. That fix changes the implementation of Math.toRadians(double) which is used by the test in initialising an AffineTransform. Math.toRadians() used to be implemented as "degrees / 180.0 * Math.PI" It is now implemented as "degrees * PRE_BAKED_CONSTANT where PRE_BAKED_CONSTANT = 0.017453292519943295 If I update the test to do "degrees / 180.0 * Math.PI" then it passes again so the issue is gone. The test runs through many values under different transform types and stops on the first one, so I cannot say - without work - what else fails, but the particular failure at which it stops is one where we rotate by -500 degrees, create an inverse, then concatenate the two and check that we have an identity transform as the result. However since scale is 0.9999999999998 (or however many decimal places is printed) and the tx type is UNIFORM_SCALE then the comparison fails. It actually would have been "GENERAL_SCALE" except that the test has a "concatfix" method which fixes similar problems in shear and translate components but does not do anything about scale. Adding that is also sufficient to make the test pass - regardless of avoiding Math.toRadians(). Here's a small test that shows the difference this makes :- import java.awt.geom.AffineTransform; public class RadTest { public static void main(String args[]) throws Exception { testRotation(Math.toRadians(-500), "MATH.RADIANS"); testRotation(-500 / 180.0 * Math.PI, "CUSTOM MATH"); } public static void testRotation(double rads, String method) throws Exception { System.out.println("Method = "+ method + " angle="+rads); AffineTransform at1 = new AffineTransform(); at1 = new AffineTransform(at1); at1.rotate(rads); AffineTransform invAt1 = at1.createInverse(); invAt1.concatenate(at1); System.out.println("restored tx="+invAt1); System.out.println("restored type = " + invAt1.getType()); System.out.println("restored scalex="+invAt1.getScaleX()); System.out.println(); } } % java RadTest Method = MATH.RADIANS angle=-8.726646259971648 restored tx=AffineTransform[[1.0, 0.0, 0.0], [-0.0, 1.0, 0.0]] restored type = 18 restored scalex=0.9999999999999998 Method = CUSTOM MATH angle=-8.726646259971647 restored tx=AffineTransform[[1.0, 0.0, 0.0], [0.0, 1.0, 0.0]] restored type = 0 restored scalex=1.0

Fails for me on Solaris SPARC too. So it is not platform specific.

This test fails for me from b33 onwards. But the test use only the AffineTransform class which hasn't changed and isn't dependent on anything else for its maths except the core numeric support in the platform -ie java.lang classes and the VM. So I suspect something changed there but I don't know what. Also this test has been there since Jan 2005 in JDK 1.6 and I don't find any report of it failing before - spuriously or otherwise.