harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Zakharov" <alexei.zakha...@gmail.com>
Subject Re: [classlib] compatibility nuances
Date Mon, 17 Jul 2006 16:40:55 GMT
IMHO since even BEA VM behave differently in this case we may qualify
this as a low-priority task, rise non-bug JIRA and postpone it until
we meet the real-world app that relies on this. Do nothing is better
than do something that we aren't really sure we should do. :)

Regards,

2006/7/17, Richard Liang <richard.liangyx@gmail.com>:
>
>
> Vladimir Gorr wrote:
> > In this case I'd like to understand what behaviour is correct
> > and what should be made to satisfy the users. I have no any preference.
> >
> Hello Vladimir,
>
> I think all of us agree that it's possible to following RI's behavior,
> Right? The question is we shall decide to follow or not. Any suggestion?
> Thanks a lot.
>
> Best regards,
> Richard.
> > Thanks,
> > Vladimir.
> >
> >
> > On 7/14/06, Alexei Zakharov <alexei.zakharov@gmail.com> wrote:
> >>
> >> Vladimir wrote:
> >> > (I believe Alexey used it to test. *Or J9 nevertheless*? IMHO it needs
> >> to
> >> > specify when same discussions start).
> >>
> >> I have tried both. And both differ from RI.
> >>
> >> Richard wrote:
> >> > For getDeclaredMethods(), J9 has the same behavior as RI.
> >>
> >> Well, there are some nuances nevertheless. I have wrote a small test
> >> (that was close to my orginal test) and ran it on four different VMs.
> >> The test simply does TestBean.class.getDeclaredMethods() and prints
> >> the resulting array.
> >>
> >> TestBean.java:
> >> class TestBean {
> >>    String methodCalled = null;
> >>
> >>    public void method(Integer i) {
> >>        methodCalled = "method1";
> >>    }
> >>
> >>    public void method(int i) {
> >>        methodCalled = "method2";
> >>    }
> >>
> >>    public void method(boolean b) {
> >>        methodCalled = "method3";
> >>    }
> >>
> >>    public void method(Boolean b) {
> >>        methodCalled = "method4";
> >>    }
> >>
> >> }
> >>
> >> The results:
> >> RI (Sun 1.5.0_05)
> >> method int
> >> method boolean
> >> method java.lang.Boolean
> >> method java.lang.Integer
> >>
> >> j9 v3
> >> method java.lang.Integer
> >> method int
> >> method boolean
> >> method java.lang.Boolean
> >>
> >> DLRVM
> >> method java.lang.Integer
> >> method int
> >> method boolean
> >> method java.lang.Boolean
> >>
> >> jrockit-R26.3.0-jdk1.5.0_06
> >> method java.lang.Boolean
> >> method boolean
> >> method int
> >> method java.lang.Integer
> >>
> >> With Best Regards,
> >>
> >> 2006/7/14, Richard Liang <richard.liangyx@gmail.com>:
> >> >
> >> >
> >> > Geir Magnusson Jr wrote:
> >> > > Alexey Varlamov 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 j9 do?
> >> > >
> >> > >
> >> > For getDeclaredMethods(), J9 has the same behavior as RI. For
> >> > getMethods, J9 and RI behave differently.   ;-)   But it's not so hard
> >> > to summarize RI's rule of method order. Am I wrong?
> >> >
> >> > Best regards,
> >> > Richard
> >> > >> I believe we need a bit stronger motivation for scratching this
> >> issue,
> >> > >> than a blunt testcase - some real-world application.
> >> > >>
> >> > >
> >> > >
> >> > > I agree that this isn't a critical issue, but a "nice to have".
> >> Maybe
> >> > > we see what J9 does, and follow the majority (if we spend the
> >> time...)?
> >> > >
> >> > > geir
> >> > --
> >> > Richard Liang
> >> > China Software Development Lab, IBM
> >>
> >> --
> >> Alexei Zakharov,
> >> Intel Middleware Product Division
> --
> Richard Liang
> China Software Development Lab, IBM


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


Mime
View raw message