harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: [classlib] compatibility nuances
Date Fri, 14 Jul 2006 11:20:57 GMT

Vladimir Gorr wrote:
> On 7/14/06, Alexey Varlamov <alexey.v.varlamov@gmail.com> wrote:
>>
>> 2006/7/14, Richard Liang <richard.liangyx@gmail.com>:
>> >
>> >
>> > Magnusson, Geir wrote:
>> > >> -----Original Message-----
>> > >> From: Alexei Zakharov [mailto:alexei.zakharov@gmail.com]
>> > >> Sent: Thursday, July 13, 2006 10:19 AM
>> > >> To: harmony-dev@incubator.apache.org; geir@pobox.com
>> > >> 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 <geir@pobox.com>:
>> > >>
>> > >>> 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: harmony-dev-unsubscribe@incubator.apache.org
>> > >> For additional commands, e-mail:
>> harmony-dev-help@incubator.apache.org
>> > >>
>> > >>
>> > >
>> > > ---------------------------------------------------------------------
>> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
>> > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> > > For additional commands, e-mail:
>> harmony-dev-help@incubator.apache.org
>> > >
>> > >
>> > >
>> >
>> > --
>> > Richard Liang
>> > China Software Development Lab, IBM
>> >
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message