Spec update for Class#getDeclaredMethods()

[Dalibor Topic]

Rémi Forax wrote:
> Florian Weimer a écrit :
>> I suggest to replace:
>>
>> | The elements [methods] in the array returned are not sorted and are
>> | not in any particular order.
>>
>> with:
>>
>> | If the class is a compiled Java class, the elements in the array are
>> | sorted according to the order of declaration in the source code.
>> | Otherwise, the elements are not in any particular order.
>>
>> There is a growing amount of code which relies on predictable method
>> order, so backwards compatibility concerns implicitly dictate the
>> ordering.  The proposed change makes this explicit.
>>
>> The other reflection methods should be updated in a similar fashion
> 
> This sentences was conscientiously added between 1.1 and 1.2
> and I know a small VM that returns the method using the vtable ordering
> for getMethod.
> 
> Your suggestion implies that potentially all VM implementors should
> change some parts of their VM
> data structures.
> Doesn't seem realistic, isn't it.

Unless the order of method declarations in the source code must be
preserved in the class file (I don't think that's the case), I don't 
think it would really be possible for JVM implementors to do that due 
to the lack of the ability to determine at runtime from the class file 
alone the 'original' permutation of the elements that corresponds to 
the one in the source code in general.

cheers,
dalibor topic
-- 
*******************************************************************
Dalibor Topic                   Tel: (+49 40) 23 646 738
Java F/OSS Ambassador           AIM: robiladonaim
Sun Microsystems GmbH           Mobile: (+49 177) 2664 192
Nagelsweg 55                    http://openjdk.java.net
D-20097 Hamburg                 mailto:Dalibor.Topic at sun.com
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht München: HRB 161028
Geschäftsführer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Häring