Vladimir Gorr wrote: > On 7/14/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote: >> >> 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: harmony-dev@incubator.apache.org; [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). >
What does IBM do? > > I agree with this assertion. The implementation of kernel classes for > DRLVM was clean room one. There's no doubt about that. > > (I believe Alexey used it to test. *Or J9 nevertheless*? IMHO it needs to > specify when same discussions start). > > We've knew nothing about the algorithms used by RI. All we knew is our > implementation should correspond to the specifications > > and not break them. The case discussed here is such one in my opinion. > Could > you please give prove why the compatibility needs here? Just convenience for users. > > What RI should be used for this purpose if any? > > > Thanks, > Vladimir. > > 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] >> >> > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
