harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Orlov" <amor...@gmail.com>
Subject Re: matching reference implementation exception behaviour
Date Mon, 03 Apr 2006 13:55:13 GMT
On 4/3/06, Mark Hindess <mark.hindess@googlemail.com> 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.

Aha, I see.

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

Mark, can we run diff with your results and ours attached to the previous mail?

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

Ok, thanks, I agree.

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

Hmm, I thought BEA uses the same class libraries... Apparently BEA and
Sun class libraries implementation should not differ that much...

Thanks,
Alex Orlov.
Intel Middleware Products Division

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