This PR fixes the error resulting from the flaky test: net.bytebuddy.implementation.auxiliary.MethodCallProxyTest.testMultipleParameterMethod.
The mentioned tests may fail or pass without changes made to the source code when it is run in different JVMs due to getDeclaredFields non-deterministic order.
Why the tests fail
This test fails because MethodCallProxyTest calls AbstractMethodCallProxyTest, and there are 2 assertions that fail which use getDeclaredFields to assert the field types.
As per the Java documentation, the getDeclaredFields method returns the array of fields, and the elements in the returned array are not sorted and are not in any particular order. So, the test fails as the given order can be different from the expected order. This has been the case since Java 1.1 version.
Reproduce the test failure
Run the tests with NonDex maven plugin. The commands to recreate the flaky test failures are:
Fixing the flaky test now may prevent flaky test failures in future Java versions.
Expected results
Both tests should run successfully when run with NonDex.
Actual Result
We get the following failure for the test:[INFO] Running net.bytebuddy.implementation.auxiliary.MethodCallProxyTest [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.423 s <<< FAILURE! - in net.bytebuddy.implementation.auxiliary.MethodCallProxyTest [ERROR]testMultipleParameterMethod(net.bytebuddy.implementation.auxiliary.MethodCallProxyTest) Time elapsed: 0.417 s <<< FAILURE! java.lang.AssertionError
Fix
For the first assertion failure, we obtain proxytarget from fields then perform an assertion if proxymethod is not static.
For the second assertion failure, we remove the proxytarget class from the fields then sort them. Further, we sort the parameter types too, then perform assertion of these array lists thus we can ensure that the getDeclaredFields order does not cause an assert failure in method net.bytebuddy.implementation.auxiliary.MethodCallProxyTest
What is the purpose of this PR
This PR fixes the error resulting from the flaky test:
net.bytebuddy.implementation.auxiliary.MethodCallProxyTest.testMultipleParameterMethod.The mentioned tests may fail or pass without changes made to the source code when it is run in different JVMs due to
getDeclaredFieldsnon-deterministic order.Why the tests fail
MethodCallProxyTestcallsAbstractMethodCallProxyTest, and there are 2 assertions that fail which usegetDeclaredFieldsto assert the field types.getDeclaredFieldsmethod returns the array of fields, and the elements in the returned array are not sorted and are not in any particular order. So, the test fails as the given order can be different from the expected order. This has been the case sinceJava 1.1version.Reproduce the test failure
Run the tests with NonDex maven plugin. The commands to recreate the flaky test failures are:
mvn -pl cli edu.illinois:nondex-maven-plugin:2.1.1:nondex -Dtest=net.bytebuddy.implementation.auxiliary.MethodCallProxyTest#testMultipleParameterMethodFixing the flaky test now may prevent flaky test failures in future Java versions.
Expected results
NonDex.Actual Result
[INFO] Running net.bytebuddy.implementation.auxiliary.MethodCallProxyTest [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.423 s <<< FAILURE! - in net.bytebuddy.implementation.auxiliary.MethodCallProxyTest [ERROR]testMultipleParameterMethod(net.bytebuddy.implementation.auxiliary.MethodCallProxyTest) Time elapsed: 0.417 s <<< FAILURE! java.lang.AssertionErrorFix
For the first assertion failure, we obtain
proxytargetfrom fields then perform an assertion ifproxymethodis not static.For the second assertion failure, we remove the
proxytargetclass from the fields then sort them. Further, we sort theparameter typestoo, then perform assertion of these array lists thus we can ensure that thegetDeclaredFieldsorder does not cause an assert failure in methodnet.bytebuddy.implementation.auxiliary.MethodCallProxyTest