harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From George Harley <george.c.har...@googlemail.com>
Subject Re: matching reference implementation exception behaviour
Date Mon, 03 Apr 2006 14:36:31 GMT
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.
>   

You mean raise JIRA's one type/package at a time don't you ? One issue 
per method sounds like it would be a bit excessive !

Best regards,
George

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


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