2006/7/14, Richard Liang <[EMAIL PROTECTED]>:
Magnusson, Geir wrote: >> -----Original Message----- >> From: Alexei Zakharov [mailto:[EMAIL PROTECTED] >> Sent: Thursday, July 13, 2006 10:19 AM >> To: [email protected]; [EMAIL PROTECTED] >> Subject: Re: [classlib] compatibility nuances >> >> >>> That our "not in any particular >>> order" is different than the "not in any particular order" >>> >> that the RI >> >>> does? I'm not trying to make light of it, but it sounds like all is >>> correct. >>> >> Right, from the spec point of view everything is correct. But I'd >> like to say that our particular order differs from RI particular order >> (and such behavior conforms to spec). My next statement is: there are >> stupid apps that rely on the particular order >> returned by RI (regardless of spec). I know one already. The question >> is: should we care or not? >> >> > > Can you figure out what their order is? If so, I'd use that since we > are free to do what we want, and if someone does depende on this, it's > one less change, and it's spec compliant. > > As well as I know, the order is what the methods are declared in java source. (Cannot find any document currently ;-) )
IIRC, Sun and JRockit behave differently to this matter, JRockit's VM reports methods in reversed order. Besides, there are 2 APIs: getDeclaredMethods() and getMethods() - we should consider both if we really care. And detecting "right" order for the last is tedious - taking into account variety of heritable methods (declared directly, inherited from superclass(es), inherited from superinterface(s), inherited from superinterfaces of superclasses). I believe we need a bit stronger motivation for scratching this issue, than a blunt testcase - some real-world application. -- Regards, Alexey Varlamov
Best regards, Richard > Geir > > > >> 2006/7/13, Geir Magnusson Jr <[EMAIL PROTECTED]>: >> >>> I assume you mean [drlvm], since java.lang.Class in >>> >> [classlib] is just a >> >>> stub, right? >>> >>> Anyway, what would you say exactly? That our "not in any particular >>> order" is different than the "not in any particular order" >>> >> that the RI >> >>> does? I'm not trying to make light of it, but it sounds like all is >>> correct. >>> >>> geir >>> >>> Alexei Zakharov wrote: >>> >>>> Hi, >>>> >>>> I have discovered we have small incompatibility in our >>>> >> java.lang.Class >> >>>> implementation. The order of elements returned by >>>> Class.getDeclaredMethods() differs from RI. The spec says >>>> >> here: "The >> >>>> elements in the array returned are not sorted and are not in any >>>> particular order." But I already know one application >>>> >> that relies on >> >>>> this - this was one of java.beans test (already patched). >>>> >> I don't want >> >>>> to say this is somehow bad but still like to inform the community >>>> about this issue. Probably we need to rise non-bug >>>> >> differences JIRA? >> >>>> Thanks, >>>> >> >> -- >> Alexei Zakharov, >> Intel Middleware Product Division >> >> --------------------------------------------------------------------- >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- Richard Liang China Software Development Lab, IBM
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
