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 Mon, 03 Apr 2006 13:52:06 GMT
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


Mime
View raw message