Bug ID: JDK-7023180 Change in specified-to-be-unspecified ordering of getDeclaredMethods causes application problems

JDK-7023180 : Change in specified-to-be-unspecified ordering of getDeclaredMethods causes application problems

Type: Bug
Component: hotspot
Sub-Component: runtime
Affected Version: 7

Priority: P2
Status: Closed
Resolution: Not an Issue
OS: generic,linux
CPU: generic,x86

Submitted: 2011-02-28
Updated: 2012-09-11
Resolved: 2011-04-07

Versions (Unresolved/Resolved/Fixed)

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.

JDK 8
8Resolved

Related Reports

Duplicate :	JDK-7081877 - Class.getDeclaredMethods0 result sometimes not in source order on JDK 7
Relates :	JDK-7016112 - CMS: crash during promotion testing
Relates :	JDK-7052494 - Eclipse test fails on JDK 7 b142
Relates :	JDK-7148504 - JMX MBeanInfo no longer guarantees equality of MBeanInfo between two identical mbeans
Relates :	JDK-6990754 - Use native memory and reference counting to implement SymbolTable

Description

Starting in build 129 of JDK 7, the order of methods returned by getDeclaredMethods changed and can vary from run to run.  This has been observed to cause issues for applications relying on the specified-to-be-unspecified ordering of methods retuned by getDeclaredMethods.

Comments

PUBLIC COMMENTS Filed a request for JUnit to behave predictably irrespective of VM order: https://github.com/KentBeck/junit/pull/293

09-09-2011

PUBLIC COMMENTS http://www.oracle.com/technetwork/java/javase/compatibility-417013.html#incompatibilities ought to mention this change.

22-08-2011

EVALUATION The previously implementation of getDeclaredMethods did not have a firm ordering guarantee and the specification does not require one. Merely returning a consistent order throughout the run of a VM would not be sufficient to address programs expecting a (mostly) sorted order. Imposing a predictable ordering is not being considered at this time; closing as not a bug.

07-04-2011