harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Gorr" <vvg...@gmail.com>
Subject Re: [classlib] compatibility nuances
Date Fri, 14 Jul 2006 04:49:03 GMT
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).



I agree with this assertion. The implementation of kernel classes for
DRLVM was clean room one.

(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?

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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message