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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
IBM Java Technology Centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mark Hindess <[EMAIL PROTECTED]>
IBM Java Technology Centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
