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 Tue, 04 Apr 2006 08:33:43 GMT
Paulex,

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

+1. IMHO this sort of "compatibility" report might be good thing.
Additionallywe will highlight that Harmony doesn't contain some RI
bugs.

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

+1 as well.

Thanks,
Alex.
Intel Middleware Products Division

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

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