harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@gmail.com>
Subject Re: matching reference implementation exception behaviour
Date Tue, 04 Apr 2006 03:55:23 GMT
Mikhail

It's good idea to compare a couple of implementations, and if so, I 
think we need some case by case discussion if they themselves have 
differences, and further we may need one difference behavior report (on 
Wiki? or JIRA maybe?) to every RI. The reports are also useful 
information to potential Harmony users.

And more, I think we need some other principles, pls. consider following 
proposals:
1. Try to comply with newest version of RI , for example, Sun JDK 
1.5.0_06 currently if we choose it as one of RI. This should be 
applicable if only we have wonderful API test suites, and I don't expect 
RI will release new version *too* frequently.
2. Try to comply with RI on same platform,  for example, Harmony on 
Linux should behave exactly like RI on Linux, while Harmony on Windows 
should like RI on Windows.

Mikhail Loenko wrote:
> Paulex,
>
> agreed, we need to define what does RI mean.
>
> I'd compare to a couple of implementations from different vendors,
> like Sun's and BEA's ones or Sun's and IBM's.
>
> What do you think?
>
> Thanks,
> Mikhail
>
>
> 2006/4/3, Paulex Yang <paulex.yang@gmail.com>:
>   
>> Mark
>>
>> You just point out a serious issue ;-) . The RI is just a concept, in
>> fact we have many RIs, Sun's JDK, BEA's JDK, even different versions,
>> Sun JDK 1.5.0, 1.5.0.04, 1.5.0.06...(even more in future I expects), and
>> on different platforms(win32, linux32, still even more in future)...In
>> fact sometimes they have different behavior themselves, it is very
>> reasonable that 1.5.06 fix some bugs of 1.5.0, so that some different
>> exceptions thrown(more reasonable IAE instead of NPE, for example), or
>> more seriously, different results returned... Samples are available upon
>> request:).
>>
>> So, I think maybe we need get some specific RI to follow? or at least,
>> newest version from a specific vendor? or just let them be? comments?
>>
>> Mark Hindess wrote:
>>     
>>> I did something similar one evening a couple of weeks back.  I raised
>>> separate JIRAs about a number of the issues I found and included fixes
>>> and test cases.  I've still got numerous outstanding issues that I
>>> haven't created JIRAs for since I was waiting to see if the existing
>>> ones got accepted first.
>>>
>>> After testing constructors I adapted my script to test all the static
>>> methods.  Again, I've got a number of issues that I've not raised
>>> JIRAs about yet.
>>>
>>> Personally, I'd raise JIRA's one at a time when you have fixes
>>> prepared.  That way they can be discussed and we can firm up our
>>> policy on matching behaviour.
>>>
>>> Incidentally, I ran the tests comparing against the Sun 5.0 reference
>>> implementation, so I wouldn't be surprised if there were conflicts
>>> between our results.
>>>
>>> Regards,
>>>  Mark.
>>>
>>>
>>> On 4/3/06, Alex Orlov <amorlov@gmail.com> wrote:
>>>
>>>       
>>>> Hi folks,
>>>>
>>>> Sorry to getting this thread back - hopefully this message is relevant
>>>> to it. We've written a tool that runs all J2SE API methods passing
>>>> null, empty strings, 0, -1 etc. as parameters. It has discovered 163
>>>> inconsistency of Harmony API implementation with BEA JRockit 1.5.0.
>>>> You can find them attached ("------------" means JRE doesn't throw any
>>>> exception).
>>>>
>>>> I haven't investigated all of them yet. However apparently we have
>>>> dozens of real inconsistencies that might be fixed according to
>>>> Harmony guidelines on exception compatibility. We're going to check
>>>> the inconsistencies one by one. Do you think it makes sense to open
>>>> one JIRA issue for all of them and put it there?
>>>>
>>>> Thanks,
>>>> Alex Orlov.
>>>> Intel Middleware products Division
>>>>
>>>> On 3/24/06, Geir Magnusson Jr <geir@pobox.com> wrote:
>>>>
>>>>         
>>>>> George Harley wrote:
>>>>>
>>>>>           
>>>>>> Mark Hindess wrote:
>>>>>>
>>>>>>             
>>>>>>> As you might have noticed, if you are reading the JIRA messages
on the
>>>>>>> commits list, I've been looking at the error case behaviour of
>>>>>>> constructors.  (In fact, I've written a Perl script to generate
a
>>>>>>> program to creates several thousand test cases from the constructor
>>>>>>> specification in a japi file.  I'll probably extend it to test
other
>>>>>>> static methods when I have a spare minute.)
>>>>>>>
>>>>>>> I'm wondering how far we should try to match the behaviour of
the
>>>>>>> reference implementation.  For instance, I've been submitting
fixes
>>>>>>> for a number of cases of incorrect exceptions being thrown and
I think
>>>>>>> they are worth fixing, but then I came across this one:
>>>>>>>
>>>>>>>   j.io.RandomAccessFile((j.l.String)null,""): # i.e. null filename,
>>>>>>> empty mode
>>>>>>>
>>>>>>> the RI throws j.l.IllegalArgumentException because it checks
the mode
>>>>>>> first but we throw a NullPointerException because we check the
file
>>>>>>> first.
>>>>>>>
>>>>>>> Does it matter?  Should we be matching behaviour?
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> Wasn't this the topic for a fairly recent discussion on the list
? If I
>>>>>> can recall correctly, the consensus seemed to be YES it matters and
YES
>>>>>> we should be matching behaviour.
>>>>>>
>>>>>>             
>>>>> Yes - if the spec doesn't say anything, and the RI isn't obviously
>>>>> broken or stupid, then follow the RI.
>>>>>
>>>>> If the spec does say something, we need to make a decision - follow the
>>>>> spec or follow the RI (and log it...)
>>>>>
>>>>> geir
>>>>>
>>>>>
>>>>>           
>>>>>> And if that wasn't the consensus then it should have been ;-)
>>>>>>
>>>>>> Best regards,
>>>>>> George
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> Regards,
>>>>>>>  Mark.
>>>>>>>
>>>>>>> --
>>>>>>> Mark Hindess <mark.hindess@googlemail.com>
>>>>>>> IBM Java Technology Centre, UK.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>> ---------------------------------------------------------------------
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>         
>>> --
>>> Mark Hindess <mark.hindess@googlemail.com>
>>> IBM Java Technology Centre, UK.
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>>
>>>
>>>
>>>       
>> --
>> Paulex Yang
>> 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
>
>
>   


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