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.
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)
Comments
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
29-10-2014
Fails for me on Solaris SPARC too. So it is not platform specific.
27-10-2014
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.