harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Liang <richard.lian...@gmail.com>
Subject Re: [classlib] compatibility nuances
Date Mon, 17 Jul 2006 11:59:19 GMT


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
>>
>> ---------------------------------------------------------------------
>> 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
View raw message