Mikhail
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.
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.
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 <[EMAIL PROTECTED]>:
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 <[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]
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
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]
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
