You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mark Hindess <ma...@googlemail.com> on 2006/03/24 18:00:24 UTC
matching reference implementation exception behaviour
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?
Regards,
Mark.
--
Mark Hindess <ma...@googlemail.com>
IBM Java Technology Centre, UK.
Re: matching reference implementation exception behaviour
Posted by Alex Orlov <am...@gmail.com>.
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 <pa...@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 <am...@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 <ge...@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 <ma...@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 <ma...@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
Re: matching reference implementation exception behaviour
Posted by Paulex Yang <pa...@gmail.com>.
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 <pa...@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 <am...@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 <ge...@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 <ma...@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 <ma...@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
Re: matching reference implementation exception behaviour
Posted by Mikhail Loenko <ml...@gmail.com>.
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 <pa...@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 <am...@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 <ge...@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 <ma...@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 <ma...@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
Re: matching reference implementation exception behaviour
Posted by Geir Magnusson Jr <ge...@pobox.com>.
LvJimmy，Jing wrote:
> Hi：
>
> I think we never dicide that we should follow RI rather than the spec.
> The spec is the first principle we should follow. However if the spec does
> not tell us the detail of an action, then it's the time to follow RI.
> That is true that RI changes from time to time in every release. :)
The issue is that we definitely want to have programs that run on
Harmony to behave like programs that run on the RI.
Why?
Because at first, no one will believe we're right. When people ask
about a problem, they won't accept the answer that "well, that's how the
spec says..." if they can get Sun, IBM and BEA's implementations to do
something different.
Of course, once we achieve world dominance, we can revisit this :)
geir
>
> 2006/4/11, Mikhail Loenko <ml...@gmail.com>:
>> BTW, when we were deciding that we follow RI rather then the spec, we
>> cared about breaking existing implementations. But if RI changed its
>> behavior
>> from being compatible to the spec in 1.4 to being incompatible in 1.5 then
>> do
>> we believe that existing applications more likely stick to the latest
>> (1.5) version?
>>
>> Or if the spec is ambiguous and RI changed behavior from 1.4 to 1.5?
>>
>> Example JIRA-266 and "Re: [jira] Created: (HARMONY-266)
>> java.security.Signature.getInstance(String,Provider) should match 5.0
>> reference implementations behaviour" mail thread.
>>
>> Thanks,
>> Mikhail
>>
>>
>
> Best Regards!
>
> Jimmy, Jing Lv
> 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
Re: matching reference implementation exception behaviour
Posted by LvJimmy，Jing <fi...@gmail.com>.
Hi：
I think we never dicide that we should follow RI rather than the spec.
The spec is the first principle we should follow. However if the spec does
not tell us the detail of an action, then it's the time to follow RI.
That is true that RI changes from time to time in every release. :)
2006/4/11, Mikhail Loenko <ml...@gmail.com>:
>
> BTW, when we were deciding that we follow RI rather then the spec, we
> cared about breaking existing implementations. But if RI changed its
> behavior
> from being compatible to the spec in 1.4 to being incompatible in 1.5 then
> do
> we believe that existing applications more likely stick to the latest
> (1.5) version?
>
> Or if the spec is ambiguous and RI changed behavior from 1.4 to 1.5?
>
> Example JIRA-266 and "Re: [jira] Created: (HARMONY-266)
> java.security.Signature.getInstance(String,Provider) should match 5.0
> reference implementations behaviour" mail thread.
>
> Thanks,
> Mikhail
>
>
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
Re: matching reference implementation exception behaviour
Posted by Stepan Mishura <st...@gmail.com>.
On 4/11/06, Mark Hindess wrote:
>
> Based on the goal of "being least confusing to users", I'm in favour
> of matching the behaviour rather than the spec when there is any doubt
> - users will expect something that runs on reference jre to run on
> harmony and fail in the same way(s).
And what if RI behaviour "is confusing to users" like in HARMONY-315? I
think in this case we should follow the spec.
> Based on the same goal, I also think matching 5.0 behaviour is the
> correct thing to do. If Harmony is going to be a 5.0 implementation
> our users will naturally expect things to behave the same way as a 5.0
> reference implementation.
>
> JIRA issues should have a clear resolution/category to record these
> decisions - and any discussion on the mailing list should be
> summarised in the JIRA so that we can refer people to the decision.
> And so that we can revisit them when, as Geir says, we have achieved
> world domination.
>
> Incidentally, it would be good to have some input on HARMONY-266 and
> HARMONY-315. (I think Stepan and I are the only ones discussing them
> and we have opposite views. ;-) See:
Yes, it would be good to hear other opinions.
Thanks,
Stepan.
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200603.mbox/%3cfcb9f9160603310453j31abfb3dj899b538e8d6e990b@mail.gmail.com%3e
>
> and:
>
>
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200604.mbox/%3c6e47b64f0604092314k5afa9ca8ia622beee30079c59@mail.gmail.com%3e
>
> Regards,
> Mark.
>
> On 4/11/06, Mikhail Loenko <ml...@gmail.com> wrote:
> > It's not too late to think about it once again and probably revisit
> > the decision.
> >
> > As I understand goal #1 is to meet needs of as many potential users as
> we can
> > and decision to be spec incompatible in favor of new hot RI version
> might be not
> > the best one.
> >
> > Thanks,
> > Mikhail
> >
> > 2006/4/11, Geir Magnusson Jr <ge...@pobox.com>:
> > > I think that people will steadily move up in versions, and maybe most
> > > importantly, we *are* trying to build Java SE 5, not J2SE 1.4...
> > >
> > > geir
> > >
> > >
> > > Mikhail Loenko wrote:
> > > > BTW, when we were deciding that we follow RI rather then the spec,
> we
> > > > cared about breaking existing implementations. But if RI changed its
> behavior
> > > > from being compatible to the spec in 1.4 to being incompatible in
> 1.5 then do
> > > > we believe that existing applications more likely stick to the
> latest
> > > > (1.5) version?
> > > >
> > > > Or if the spec is ambiguous and RI changed behavior from 1.4 to 1.5?
> > > >
> > > > Example JIRA-266 and "Re: [jira] Created: (HARMONY-266)
> > > > java.security.Signature.getInstance(String,Provider) should match
> 5.0
> > > > reference implementations behaviour" mail thread.
> > > >
> > > > Thanks,
> > > > Mikhail
> > > >
> > > >
> > > > 2006/4/11, Geir Magnusson Jr <ge...@pobox.com>:
> > > >>
> > > >> Paulex Yang wrote:
> > > >>> 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:).
> > > >> Actually, there only is one RI for any given spec, and in this
> case, I
> > > >> guess we judge it to be the latest version of a spec that comes
> from
> > > >> Sun? (The question isn't if it comes from Sun - as the spec lead,
> they
> > > >> supply the RI - but rather what version...)
> > > >>
> > > >> geir
>
> --
> Mark Hindess <ma...@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
Thanks,
Stepan Mishura
Intel Middleware Products Division
Re: matching reference implementation exception behaviour
Posted by Mark Hindess <ma...@googlemail.com>.
On 4/13/06, Stepan Mishura <st...@gmail.com> wrote:
> On 4/11/06, Mark Hindess wrote:
> >
> > Based on the goal of "being least confusing to users", I'm in favour
> > of matching the behaviour rather than the spec when there is any doubt
> > - users will expect something that runs on reference jre to run on
> > harmony and fail in the same way(s).
> >
> > Based on the same goal, I also think matching 5.0 behaviour is the
> > correct thing to do. If Harmony is going to be a 5.0 implementation
> > our users will naturally expect things to behave the same way as a 5.0
> > reference implementation.
> >
> > JIRA issues should have a clear resolution/category to record these
> > decisions - and any discussion on the mailing list should be
> > summarised in the JIRA so that we can refer people to the decision.
> > And so that we can revisit them when, as Geir says, we have achieved
> > world domination.
> >
> > Incidentally, it would be good to have some input on HARMONY-266 and
> > HARMONY-315. (I think Stepan and I are the only ones discussing them
> > and we have opposite views. ;-) See:
>
>
> Mark, as far as there are no other opinions I'd suggest to fix HARMONY-315
> in case of null provider and leave this JIRA issue open for a while. What do
> you think?
Sounds like a good plan. Thanks Stepan.
Hopefully others will step up with opinions about the other two cases.
Regards,
Mark.
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200603.mbox/%3cfcb9f9160603310453j31abfb3dj899b538e8d6e990b@mail.gmail.com%3e
> >
> > and:
> >
> >
> > http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200604.mbox/%3c6e47b64f0604092314k5afa9ca8ia622beee30079c59@mail.gmail.com%3e
> >
> > Regards,
> > Mark.
> >
> > On 4/11/06, Mikhail Loenko <ml...@gmail.com> wrote:
> > > It's not too late to think about it once again and probably revisit
> > > the decision.
> > >
> > > As I understand goal #1 is to meet needs of as many potential users as
> > we can
> > > and decision to be spec incompatible in favor of new hot RI version
> > might be not
> > > the best one.
> > >
> > > Thanks,
> > > Mikhail
> > >
> > > 2006/4/11, Geir Magnusson Jr <ge...@pobox.com>:
> > > > I think that people will steadily move up in versions, and maybe most
> > > > importantly, we *are* trying to build Java SE 5, not J2SE 1.4...
> > > >
> > > > geir
> > > >
> > > >
> > > > Mikhail Loenko wrote:
> > > > > BTW, when we were deciding that we follow RI rather then the spec,
> > we
> > > > > cared about breaking existing implementations. But if RI changed its
> > behavior
> > > > > from being compatible to the spec in 1.4 to being incompatible in
> > 1.5 then do
> > > > > we believe that existing applications more likely stick to the
> > latest
> > > > > (1.5) version?
> > > > >
> > > > > Or if the spec is ambiguous and RI changed behavior from 1.4 to 1.5?
> > > > >
> > > > > Example JIRA-266 and "Re: [jira] Created: (HARMONY-266)
> > > > > java.security.Signature.getInstance(String,Provider) should match
> > 5.0
> > > > > reference implementations behaviour" mail thread.
> > > > >
> > > > > Thanks,
> > > > > Mikhail
> > > > >
> > > > >
> > > > > 2006/4/11, Geir Magnusson Jr <ge...@pobox.com>:
> > > > >>
> > > > >> Paulex Yang wrote:
> > > > >>> 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:).
> > > > >> Actually, there only is one RI for any given spec, and in this
> > case, I
> > > > >> guess we judge it to be the latest version of a spec that comes
> > from
> > > > >> Sun? (The question isn't if it comes from Sun - as the spec lead,
> > they
> > > > >> supply the RI - but rather what version...)
> > > > >>
> > > > >> geir
> >
> > --
> > Mark Hindess <ma...@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
>
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
>
>
--
Mark Hindess <ma...@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
Re: matching reference implementation exception behaviour
Posted by Stepan Mishura <st...@gmail.com>.
On 4/11/06, Mark Hindess wrote:
>
> Based on the goal of "being least confusing to users", I'm in favour
> of matching the behaviour rather than the spec when there is any doubt
> - users will expect something that runs on reference jre to run on
> harmony and fail in the same way(s).
>
> Based on the same goal, I also think matching 5.0 behaviour is the
> correct thing to do. If Harmony is going to be a 5.0 implementation
> our users will naturally expect things to behave the same way as a 5.0
> reference implementation.
>
> JIRA issues should have a clear resolution/category to record these
> decisions - and any discussion on the mailing list should be
> summarised in the JIRA so that we can refer people to the decision.
> And so that we can revisit them when, as Geir says, we have achieved
> world domination.
>
> Incidentally, it would be good to have some input on HARMONY-266 and
> HARMONY-315. (I think Stepan and I are the only ones discussing them
> and we have opposite views. ;-) See:
Mark, as far as there are no other opinions I'd suggest to fix HARMONY-315
in case of null provider and leave this JIRA issue open for a while. What do
you think?
Thanks,
Stepan.
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200603.mbox/%3cfcb9f9160603310453j31abfb3dj899b538e8d6e990b@mail.gmail.com%3e
>
> and:
>
>
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200604.mbox/%3c6e47b64f0604092314k5afa9ca8ia622beee30079c59@mail.gmail.com%3e
>
> Regards,
> Mark.
>
> On 4/11/06, Mikhail Loenko <ml...@gmail.com> wrote:
> > It's not too late to think about it once again and probably revisit
> > the decision.
> >
> > As I understand goal #1 is to meet needs of as many potential users as
> we can
> > and decision to be spec incompatible in favor of new hot RI version
> might be not
> > the best one.
> >
> > Thanks,
> > Mikhail
> >
> > 2006/4/11, Geir Magnusson Jr <ge...@pobox.com>:
> > > I think that people will steadily move up in versions, and maybe most
> > > importantly, we *are* trying to build Java SE 5, not J2SE 1.4...
> > >
> > > geir
> > >
> > >
> > > Mikhail Loenko wrote:
> > > > BTW, when we were deciding that we follow RI rather then the spec,
> we
> > > > cared about breaking existing implementations. But if RI changed its
> behavior
> > > > from being compatible to the spec in 1.4 to being incompatible in
> 1.5 then do
> > > > we believe that existing applications more likely stick to the
> latest
> > > > (1.5) version?
> > > >
> > > > Or if the spec is ambiguous and RI changed behavior from 1.4 to 1.5?
> > > >
> > > > Example JIRA-266 and "Re: [jira] Created: (HARMONY-266)
> > > > java.security.Signature.getInstance(String,Provider) should match
> 5.0
> > > > reference implementations behaviour" mail thread.
> > > >
> > > > Thanks,
> > > > Mikhail
> > > >
> > > >
> > > > 2006/4/11, Geir Magnusson Jr <ge...@pobox.com>:
> > > >>
> > > >> Paulex Yang wrote:
> > > >>> 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:).
> > > >> Actually, there only is one RI for any given spec, and in this
> case, I
> > > >> guess we judge it to be the latest version of a spec that comes
> from
> > > >> Sun? (The question isn't if it comes from Sun - as the spec lead,
> they
> > > >> supply the RI - but rather what version...)
> > > >>
> > > >> geir
>
> --
> Mark Hindess <ma...@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
Thanks,
Stepan Mishura
Intel Middleware Products Division
Re: matching reference implementation exception behaviour
Posted by Mark Hindess <ma...@googlemail.com>.
Based on the goal of "being least confusing to users", I'm in favour
of matching the behaviour rather than the spec when there is any doubt
- users will expect something that runs on reference jre to run on
harmony and fail in the same way(s).
Based on the same goal, I also think matching 5.0 behaviour is the
correct thing to do. If Harmony is going to be a 5.0 implementation
our users will naturally expect things to behave the same way as a 5.0
reference implementation.
JIRA issues should have a clear resolution/category to record these
decisions - and any discussion on the mailing list should be
summarised in the JIRA so that we can refer people to the decision.
And so that we can revisit them when, as Geir says, we have achieved
world domination.
Incidentally, it would be good to have some input on HARMONY-266 and
HARMONY-315. (I think Stepan and I are the only ones discussing them
and we have opposite views. ;-) See:
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200603.mbox/%3cfcb9f9160603310453j31abfb3dj899b538e8d6e990b@mail.gmail.com%3e
and:
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200604.mbox/%3c6e47b64f0604092314k5afa9ca8ia622beee30079c59@mail.gmail.com%3e
Regards,
Mark.
On 4/11/06, Mikhail Loenko <ml...@gmail.com> wrote:
> It's not too late to think about it once again and probably revisit
> the decision.
>
> As I understand goal #1 is to meet needs of as many potential users as we can
> and decision to be spec incompatible in favor of new hot RI version might be not
> the best one.
>
> Thanks,
> Mikhail
>
> 2006/4/11, Geir Magnusson Jr <ge...@pobox.com>:
> > I think that people will steadily move up in versions, and maybe most
> > importantly, we *are* trying to build Java SE 5, not J2SE 1.4...
> >
> > geir
> >
> >
> > Mikhail Loenko wrote:
> > > BTW, when we were deciding that we follow RI rather then the spec, we
> > > cared about breaking existing implementations. But if RI changed its behavior
> > > from being compatible to the spec in 1.4 to being incompatible in 1.5 then do
> > > we believe that existing applications more likely stick to the latest
> > > (1.5) version?
> > >
> > > Or if the spec is ambiguous and RI changed behavior from 1.4 to 1.5?
> > >
> > > Example JIRA-266 and "Re: [jira] Created: (HARMONY-266)
> > > java.security.Signature.getInstance(String,Provider) should match 5.0
> > > reference implementations behaviour" mail thread.
> > >
> > > Thanks,
> > > Mikhail
> > >
> > >
> > > 2006/4/11, Geir Magnusson Jr <ge...@pobox.com>:
> > >>
> > >> Paulex Yang wrote:
> > >>> 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:).
> > >> Actually, there only is one RI for any given spec, and in this case, I
> > >> guess we judge it to be the latest version of a spec that comes from
> > >> Sun? (The question isn't if it comes from Sun - as the spec lead, they
> > >> supply the RI - but rather what version...)
> > >>
> > >> geir
--
Mark Hindess <ma...@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
Re: matching reference implementation exception behaviour
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Mark Hindess wrote:
> On 4/11/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>> Mikhail Loenko wrote:
>>> It's not too late to think about it once again and probably revisit
>>> the decision.
>> BTW, I don't think of this as a blanket rule-of-law, but rather a
>> guideline, a motivation for how we make decisions on a bug-by-bug or
>> issue-by-issue basis.
>>
>>> As I understand goal #1 is to meet needs of as many potential users as we can
>>> and decision to be spec incompatible in favor of new hot RI version might be
>>> not the best one.
>> I think I agree :)
>
> Mikhail makes it sound like this is just an aberation in the RI - and
> I might agree with you/him if I thought that is what it was - but as I
> mention earlier both IBM and BEA implementations have the same
> behaviour.
It might be because they use the same class library as the RI :)
> Do we really want to take a different path to what must be
> the most common 5.0 implementations?
No, and I'm not sure why you think I disagree with that.
geir
---------------------------------------------------------------------
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
Re: matching reference implementation exception behaviour
Posted by Mark Hindess <ma...@googlemail.com>.
On 4/11/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
> Mikhail Loenko wrote:
> > It's not too late to think about it once again and probably revisit
> > the decision.
>
> BTW, I don't think of this as a blanket rule-of-law, but rather a
> guideline, a motivation for how we make decisions on a bug-by-bug or
> issue-by-issue basis.
>
> > As I understand goal #1 is to meet needs of as many potential users as we can
> > and decision to be spec incompatible in favor of new hot RI version might be
> > not the best one.
>
> I think I agree :)
Mikhail makes it sound like this is just an aberation in the RI - and
I might agree with you/him if I thought that is what it was - but as I
mention earlier both IBM and BEA implementations have the same
behaviour. Do we really want to take a different path to what must be
the most common 5.0 implementations?
Regards,
Mark.
--
Mark Hindess <ma...@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
Re: matching reference implementation exception behaviour
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Mikhail Loenko wrote:
> It's not too late to think about it once again and probably revisit
> the decision.
BTW, I don't think of this as a blanket rule-of-law, but rather a
guideline, a motivation for how we make decisions on a bug-by-bug or
issue-by-issue basis.
>
> As I understand goal #1 is to meet needs of as many potential users as we can
> and decision to be spec incompatible in favor of new hot RI version might be not
> the best one.
I think I agree :)
geir
>
> Thanks,
> Mikhail
>
> 2006/4/11, Geir Magnusson Jr <ge...@pobox.com>:
>> I think that people will steadily move up in versions, and maybe most
>> importantly, we *are* trying to build Java SE 5, not J2SE 1.4...
>>
>> geir
>>
>>
>> Mikhail Loenko wrote:
>>> BTW, when we were deciding that we follow RI rather then the spec, we
>>> cared about breaking existing implementations. But if RI changed its behavior
>>> from being compatible to the spec in 1.4 to being incompatible in 1.5 then do
>>> we believe that existing applications more likely stick to the latest
>>> (1.5) version?
>>>
>>> Or if the spec is ambiguous and RI changed behavior from 1.4 to 1.5?
>>>
>>> Example JIRA-266 and "Re: [jira] Created: (HARMONY-266)
>>> java.security.Signature.getInstance(String,Provider) should match 5.0
>>> reference implementations behaviour" mail thread.
>>>
>>> Thanks,
>>> Mikhail
>>>
>>>
>>> 2006/4/11, Geir Magnusson Jr <ge...@pobox.com>:
>>>> Paulex Yang wrote:
>>>>> 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:).
>>>> Actually, there only is one RI for any given spec, and in this case, I
>>>> guess we judge it to be the latest version of a spec that comes from
>>>> Sun? (The question isn't if it comes from Sun - as the spec lead, they
>>>> supply the RI - but rather what version...)
>>>>
>>>> geir
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
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
Re: matching reference implementation exception behaviour
Posted by Mikhail Loenko <ml...@gmail.com>.
It's not too late to think about it once again and probably revisit
the decision.
As I understand goal #1 is to meet needs of as many potential users as we can
and decision to be spec incompatible in favor of new hot RI version might be not
the best one.
Thanks,
Mikhail
2006/4/11, Geir Magnusson Jr <ge...@pobox.com>:
> I think that people will steadily move up in versions, and maybe most
> importantly, we *are* trying to build Java SE 5, not J2SE 1.4...
>
> geir
>
>
> Mikhail Loenko wrote:
> > BTW, when we were deciding that we follow RI rather then the spec, we
> > cared about breaking existing implementations. But if RI changed its behavior
> > from being compatible to the spec in 1.4 to being incompatible in 1.5 then do
> > we believe that existing applications more likely stick to the latest
> > (1.5) version?
> >
> > Or if the spec is ambiguous and RI changed behavior from 1.4 to 1.5?
> >
> > Example JIRA-266 and "Re: [jira] Created: (HARMONY-266)
> > java.security.Signature.getInstance(String,Provider) should match 5.0
> > reference implementations behaviour" mail thread.
> >
> > Thanks,
> > Mikhail
> >
> >
> > 2006/4/11, Geir Magnusson Jr <ge...@pobox.com>:
> >>
> >> Paulex Yang wrote:
> >>> 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:).
> >> Actually, there only is one RI for any given spec, and in this case, I
> >> guess we judge it to be the latest version of a spec that comes from
> >> Sun? (The question isn't if it comes from Sun - as the spec lead, they
> >> supply the RI - but rather what version...)
> >>
> >> geir
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >
> >
>
> ---------------------------------------------------------------------
> 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
Re: matching reference implementation exception behaviour
Posted by Geir Magnusson Jr <ge...@pobox.com>.
I think that people will steadily move up in versions, and maybe most
importantly, we *are* trying to build Java SE 5, not J2SE 1.4...
geir
Mikhail Loenko wrote:
> BTW, when we were deciding that we follow RI rather then the spec, we
> cared about breaking existing implementations. But if RI changed its behavior
> from being compatible to the spec in 1.4 to being incompatible in 1.5 then do
> we believe that existing applications more likely stick to the latest
> (1.5) version?
>
> Or if the spec is ambiguous and RI changed behavior from 1.4 to 1.5?
>
> Example JIRA-266 and "Re: [jira] Created: (HARMONY-266)
> java.security.Signature.getInstance(String,Provider) should match 5.0
> reference implementations behaviour" mail thread.
>
> Thanks,
> Mikhail
>
>
> 2006/4/11, Geir Magnusson Jr <ge...@pobox.com>:
>>
>> Paulex Yang wrote:
>>> 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:).
>> Actually, there only is one RI for any given spec, and in this case, I
>> guess we judge it to be the latest version of a spec that comes from
>> Sun? (The question isn't if it comes from Sun - as the spec lead, they
>> supply the RI - but rather what version...)
>>
>> geir
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
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
Re: matching reference implementation exception behaviour
Posted by Mikhail Loenko <ml...@gmail.com>.
BTW, when we were deciding that we follow RI rather then the spec, we
cared about breaking existing implementations. But if RI changed its behavior
from being compatible to the spec in 1.4 to being incompatible in 1.5 then do
we believe that existing applications more likely stick to the latest
(1.5) version?
Or if the spec is ambiguous and RI changed behavior from 1.4 to 1.5?
Example JIRA-266 and "Re: [jira] Created: (HARMONY-266)
java.security.Signature.getInstance(String,Provider) should match 5.0
reference implementations behaviour" mail thread.
Thanks,
Mikhail
2006/4/11, Geir Magnusson Jr <ge...@pobox.com>:
>
>
> Paulex Yang wrote:
> > 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:).
>
> Actually, there only is one RI for any given spec, and in this case, I
> guess we judge it to be the latest version of a spec that comes from
> Sun? (The question isn't if it comes from Sun - as the spec lead, they
> supply the RI - but rather what version...)
>
> geir
>
> ---------------------------------------------------------------------
> 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
Re: matching reference implementation exception behaviour
Posted by LvJimmy，Jing <fi...@gmail.com>.
2006/4/11, Paulex Yang <pa...@gmail.com>:
>
> Geir Magnusson Jr wrote:
> >
> >
> > Paulex Yang wrote:
> >> 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:).
> >
> > Actually, there only is one RI for any given spec, and in this case, I
> > guess we judge it to be the latest version of a spec that comes from
> > Sun? (The question isn't if it comes from Sun - as the spec lead, they
> > supply the RI - but rather what version...)
> Yes, I agree with you, there should be only one RI. And I suggest to
> stick with Sun's 1.5.0 with latest revision (i.e. 1.5.0_06 by now).
Agree:)
>
> > geir
> >
> > ---------------------------------------------------------------------
> > 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
>
>
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
Re: matching reference implementation exception behaviour
Posted by Paulex Yang <pa...@gmail.com>.
Geir Magnusson Jr wrote:
>
>
> Paulex Yang wrote:
>> 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:).
>
> Actually, there only is one RI for any given spec, and in this case, I
> guess we judge it to be the latest version of a spec that comes from
> Sun? (The question isn't if it comes from Sun - as the spec lead, they
> supply the RI - but rather what version...)
Yes, I agree with you, there should be only one RI. And I suggest to
stick with Sun's 1.5.0 with latest revision (i.e. 1.5.0_06 by now).
>
> geir
>
> ---------------------------------------------------------------------
> 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
Re: matching reference implementation exception behaviour
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Paulex Yang wrote:
> 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:).
Actually, there only is one RI for any given spec, and in this case, I
guess we judge it to be the latest version of a spec that comes from
Sun? (The question isn't if it comes from Sun - as the spec lead, they
supply the RI - but rather what version...)
geir
---------------------------------------------------------------------
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
Re: matching reference implementation exception behaviour
Posted by Paulex Yang <pa...@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 <am...@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 <ge...@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 <ma...@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 <ma...@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
Re: matching reference implementation exception behaviour
Posted by George Harley <ge...@googlemail.com>.
Mark Hindess wrote:
> On 4/3/06, George Harley <ge...@googlemail.com> wrote:
>
>> Mark Hindess wrote:
>>
>>> 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 !
>>
>
> I was assuming one JIRA per issue was a given. I obviously wasn't
> suggesting splitting a single issue across multiple JIRAs. I wouldn't
> want to overload our committers! ;-)
>
> I was just suggesting that we don't bundle up similar but clearly
> unrelated issues together. For instance, we shouldn't bundle issues
> such as "java.lang.String.valueOf(null)" and
> "java.beans.Encoder.writeExpression(null)" not throwing
> NullPointerExceptions together.
>
Sure. Agreed.
Best regards,
George
> Regards,
> Mark.
>
> --
> Mark Hindess <ma...@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
Re: matching reference implementation exception behaviour
Posted by Mark Hindess <ma...@googlemail.com>.
On 4/3/06, George Harley <ge...@googlemail.com> wrote:
>
> Mark Hindess wrote:
> >
> > 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 !
I was assuming one JIRA per issue was a given. I obviously wasn't
suggesting splitting a single issue across multiple JIRAs. I wouldn't
want to overload our committers! ;-)
I was just suggesting that we don't bundle up similar but clearly
unrelated issues together. For instance, we shouldn't bundle issues
such as "java.lang.String.valueOf(null)" and
"java.beans.Encoder.writeExpression(null)" not throwing
NullPointerExceptions together.
Regards,
Mark.
--
Mark Hindess <ma...@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
Re: matching reference implementation exception behaviour
Posted by George Harley <ge...@googlemail.com>.
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 <am...@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 <ge...@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 <ma...@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 <ma...@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
Re: matching reference implementation exception behaviour
Posted by Tim Ellison <t....@gmail.com>.
Anton Avtamonov wrote:
> On 4/3/06, Tim Ellison <t....@gmail.com> wrote:
>> Anton Avtamonov wrote:
<snip>
>>> The way how we document them is a special JIRA category, right? So,
>>> tracking each deviation independent allows us to discuss them and
>>> change the category in case we would like to preserve the deviation.
>>> Makes sense?
>> Is anyone suggesting that these should not be fixed?
>
> Well, probably I expressed my idea not clearly enough, sorry for that.
> What I tried to say is that if we have separate jira issue for each
> deviation and then will be decided that the deviation should not be
> fixed we can easily change the category ('Component/s' field) of this
> issue to be 'Non-bug differences from RI'.
> At the other hand, if we have several differences in the single jira
> issue and then decide that one of the differences should not be fixed
> we will have to create a separate jira record to document this
> deviation.
I hope that we will have so few deviations that the second approach
seems preferable to me -- but I don't feel strongly about it.
Regards
Tim
--
Tim Ellison (t.p.ellison@gmail.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
Re: matching reference implementation exception behaviour
Posted by Anton Avtamonov <an...@gmail.com>.
On 4/3/06, Tim Ellison <t....@gmail.com> wrote:
> Anton Avtamonov wrote:
> > On 4/3/06, Mark Hindess <ma...@googlemail.com> wrote:
> > [SNIP]
> >> 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.
> >>
> >
> > Not completely agree. I believe bug report should be done immediately
> > when the problem is discovered. That is the only garantee it is never
> > lost. Besides, sometimes a person who found a problem and a person who
> > makes a patch are
> > not the same :-).
>
> You are right, I should not assume that Alex is in a position to submit
> patches/tests (we would not expect that of our 'end users').
>
> If Alex cannot provide patches then I'd vote for submitting the script
> itself so that Harmony developers can run it and fix the problems.
>
> > Talking about the original Alex's question I think we should have
> > separate JIRA issues for each diffirence. As I remember we decided to
> > document all the deviations and discuss them if they are not trivial.
>
> I thought the conclusion was to document agreed departures in this way
> -- simple bugs that show we don't behave the same as the RI should just
> be fixed.
>
> > The way how we document them is a special JIRA category, right? So,
> > tracking each deviation independent allows us to discuss them and
> > change the category in case we would like to preserve the deviation.
> > Makes sense?
>
> Is anyone suggesting that these should not be fixed?
Well, probably I expressed my idea not clearly enough, sorry for that.
What I tried to say is that if we have separate jira issue for each
deviation and then will be decided that the deviation should not be
fixed we can easily change the category ('Component/s' field) of this
issue to be 'Non-bug differences from RI'.
At the other hand, if we have several differences in the single jira
issue and then decide that one of the differences should not be fixed
we will have to create a separate jira record to document this
deviation.
--
Anton Avtamonov,
Intel Middleware Products Division
---------------------------------------------------------------------
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
Re: matching reference implementation exception behaviour
Posted by LvJimmy，Jing <fi...@gmail.com>.
Hi George:
That sounds great!:)
You meaning, in this way, we shall divide one testcase, e.g.,
FileChannelTest, into two parts, one contain tests that pass on windows and
the other with Linux? And the list of "should fix" contains some testcases
that require special environment or need a fix?
And in Harmony's plan, more platform is to be supported. In this case,
maybe some other attribute can be added to the exclude list.
This is a good idea! So shall we name the test files as
"***TestLinux32/win32.java" and add it to exclude list?
2006/4/10, George Harley <ge...@googlemail.com>:
>
> LvJimmy，Jing wrote:
> > Hi All:
> >
> > Another thing requires our attention is that RI itself, I meaning
> > Sun,IBM, BEA or so, does not perform the same in different platforms.
> That
> > is reasonable as the Operation-Systems do not work in the same way. For
> an
> > example, these differences appear very frequently on network functions.
> As a
> > result, it seems very difficult for us to write testcases on them.
> > Currently, as Harmony only supports windows and Linux, one possible
> but
> > bad solution is that get system properity "OS" in our unit testcase, use
> > different parameters in testcases by telling whether it is Linux or
> windows.
> > Another solution we comment out these testcases, or add them into
> "exclude
> > testcase list" when apply our patch, as we do recently. Both solutions
> are
> > not so proper.
> >
>
> Hi Jimmy,
>
> The (infamous) exclusion list brings with it the ability to exclude
> named test case methods if they are being run on a specific name
> platform [1]. That would remove both the need to comment out methods in
> the test case class (and with it the dependency on the developer
> remembering to go back and uncomment the method in the future) as well
> as the need for peppering the test code with operating system detection
> code and multiple different code paths. Result : cleaner test code and
> one list containing all of the test methods that may or may not get run
> depending on platform etc.
>
> Best regards,
> George
>
> [1] =
>
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/%3c43F49BD2.6070801@gmail.com%3e
>
>
> > Perhaps we shall find other ways to run different test cases
> according
> > to different OS, like Harmony build system do. Who has any opinions?
> >
> > Best Regards!
> >
> > Jimmy, Jing Lv
> > 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
>
>
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
Re: matching reference implementation exception behaviour
Posted by George Harley <ge...@googlemail.com>.
LvJimmy，Jing wrote:
> Hi All:
>
> Another thing requires our attention is that RI itself, I meaning
> Sun,IBM, BEA or so, does not perform the same in different platforms. That
> is reasonable as the Operation-Systems do not work in the same way. For an
> example, these differences appear very frequently on network functions. As a
> result, it seems very difficult for us to write testcases on them.
> Currently, as Harmony only supports windows and Linux, one possible but
> bad solution is that get system properity "OS" in our unit testcase, use
> different parameters in testcases by telling whether it is Linux or windows.
> Another solution we comment out these testcases, or add them into "exclude
> testcase list" when apply our patch, as we do recently. Both solutions are
> not so proper.
>
Hi Jimmy,
The (infamous) exclusion list brings with it the ability to exclude
named test case methods if they are being run on a specific name
platform [1]. That would remove both the need to comment out methods in
the test case class (and with it the dependency on the developer
remembering to go back and uncomment the method in the future) as well
as the need for peppering the test code with operating system detection
code and multiple different code paths. Result : cleaner test code and
one list containing all of the test methods that may or may not get run
depending on platform etc.
Best regards,
George
[1] =
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/%3c43F49BD2.6070801@gmail.com%3e
> Perhaps we shall find other ways to run different test cases according
> to different OS, like Harmony build system do. Who has any opinions?
>
> Best Regards!
>
> Jimmy, Jing Lv
> 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
Re: matching reference implementation exception behaviour
Posted by LvJimmy，Jing <fi...@gmail.com>.
Hi All:
Another thing requires our attention is that RI itself, I meaning
Sun,IBM, BEA or so, does not perform the same in different platforms. That
is reasonable as the Operation-Systems do not work in the same way. For an
example, these differences appear very frequently on network functions. As a
result, it seems very difficult for us to write testcases on them.
Currently, as Harmony only supports windows and Linux, one possible but
bad solution is that get system properity "OS" in our unit testcase, use
different parameters in testcases by telling whether it is Linux or windows.
Another solution we comment out these testcases, or add them into "exclude
testcase list" when apply our patch, as we do recently. Both solutions are
not so proper.
Perhaps we shall find other ways to run different test cases according
to different OS, like Harmony build system do. Who has any opinions?
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
Re: matching reference implementation exception behaviour
Posted by Alex Orlov <am...@gmail.com>.
On 4/3/06, Tim Ellison <t....@gmail.com> wrote:
> Anton Avtamonov wrote:
> > On 4/3/06, Mark Hindess <ma...@googlemail.com> wrote:
> > [SNIP]
> >> 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.
> >>
> >
> > Not completely agree. I believe bug report should be done immediately
> > when the problem is discovered. That is the only garantee it is never
> > lost. Besides, sometimes a person who found a problem and a person who
> > makes a patch are
> > not the same :-).
>
> You are right, I should not assume that Alex is in a position to submit
> patches/tests (we would not expect that of our 'end users').
>
> If Alex cannot provide patches then I'd vote for submitting the script
> itself so that Harmony developers can run it and fix the problems.
Tim, I believe we've been starting investigation of those issues
whether they need fixes or not. All appropriate issues will be
submitted to JIRA along with the patches.
Thanks,
Alex.
Intel Middleware Products Division
> > Talking about the original Alex's question I think we should have
> > separate JIRA issues for each diffirence. As I remember we decided to
> > document all the deviations and discuss them if they are not trivial.
>
> I thought the conclusion was to document agreed departures in this way
> -- simple bugs that show we don't behave the same as the RI should just
> be fixed.
>
> > The way how we document them is a special JIRA category, right? So,
> > tracking each deviation independent allows us to discuss them and
> > change the category in case we would like to preserve the deviation.
> > Makes sense?
>
> Is anyone suggesting that these should not be fixed?
>
> Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.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
Re: matching reference implementation exception behaviour
Posted by Tim Ellison <t....@gmail.com>.
Anton Avtamonov wrote:
> On 4/3/06, Mark Hindess <ma...@googlemail.com> wrote:
> [SNIP]
>> 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.
>>
>
> Not completely agree. I believe bug report should be done immediately
> when the problem is discovered. That is the only garantee it is never
> lost. Besides, sometimes a person who found a problem and a person who
> makes a patch are
> not the same :-).
You are right, I should not assume that Alex is in a position to submit
patches/tests (we would not expect that of our 'end users').
If Alex cannot provide patches then I'd vote for submitting the script
itself so that Harmony developers can run it and fix the problems.
> Talking about the original Alex's question I think we should have
> separate JIRA issues for each diffirence. As I remember we decided to
> document all the deviations and discuss them if they are not trivial.
I thought the conclusion was to document agreed departures in this way
-- simple bugs that show we don't behave the same as the RI should just
be fixed.
> The way how we document them is a special JIRA category, right? So,
> tracking each deviation independent allows us to discuss them and
> change the category in case we would like to preserve the deviation.
> Makes sense?
Is anyone suggesting that these should not be fixed?
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.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
Re: matching reference implementation exception behaviour
Posted by Anton Avtamonov <an...@gmail.com>.
On 4/3/06, Mark Hindess <ma...@googlemail.com> wrote:
[SNIP]
>
> 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.
>
Not completely agree. I believe bug report should be done immediately
when the problem is discovered. That is the only garantee it is never
lost. Besides, sometimes a person who found a problem and a person who
makes a patch are
not the same :-).
Talking about the original Alex's question I think we should have
separate JIRA issues for each diffirence. As I remember we decided to
document all the deviations and discuss them if they are not trivial.
The way how we document them is a special JIRA category, right? So,
tracking each deviation independent allows us to discuss them and
change the category in case we would like to preserve the deviation.
Makes sense?
--
Anton Avtamonov,
Intel Middleware Products Division
---------------------------------------------------------------------
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
Re: matching reference implementation exception behaviour
Posted by Alex Orlov <am...@gmail.com>.
> Alex, I've uploaded the scripts that I've been using to generate test case as:
>
> http://issues.apache.org/jira/browse/HARMONY-325
>
> I'd be interested in any comments/suggestions.
Oops, sorry, apparently I missed that e-mail. Surely we'll try it and
compare with our one.
Many thanks,
Alex Orlov.
Intel Middleware Products Division
>
> Regards,
> Mark.
>
> --
> Mark Hindess <ma...@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
Re: matching reference implementation exception behaviour
Posted by Mark Hindess <ma...@googlemail.com>.
On 4/3/06, Alex Orlov <am...@gmail.com> wrote:
> On 4/3/06, Mark Hindess <ma...@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?
Alex, I've uploaded the scripts that I've been using to generate test case as:
http://issues.apache.org/jira/browse/HARMONY-325
I'd be interested in any comments/suggestions.
Regards,
Mark.
--
Mark Hindess <ma...@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
Re: matching reference implementation exception behaviour
Posted by Alex Orlov <am...@gmail.com>.
On 4/3/06, Mark Hindess <ma...@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 <am...@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 <ge...@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 <ma...@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 <ma...@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
Re: matching reference implementation exception behaviour
Posted by Mark Hindess <ma...@googlemail.com>.
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 <am...@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 <ge...@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 <ma...@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 <ma...@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
Re: matching reference implementation exception behaviour
Posted by Alex Orlov <am...@gmail.com>.
On 4/3/06, Tim Ellison <t....@gmail.com> wrote:
> Alex Orlov 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?
>
> Probably makes sense to group them into either one type (where there are
> a few issues for a given type) or one module rather than all together,
> since I'm assuming that would be too big when you have included the
> proposed fix and test case (hint, hint) ;-)
Thanks, make/common sense. :)
Alex Orlov.
Intel Middleware Products Division
>
> Regards,
> Tim
>
> > Thanks,
> > Alex Orlov.
> > Intel Middleware products Division
> >
> > On 3/24/06, Geir Magnusson Jr <ge...@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 <ma...@googlemail.com>
> >>>> IBM Java Technology Centre, UK.
> >>>>
> >>>>
> >>>
> >>
> >> ------------------------------------------------------------------------
> >>
> >> METHOD Harmony BEA
> >>
> >> java.beans.beancontext.BeanContextServicesSupport.getCurrentServiceSelectors(null) java.lang.NullPointerException --------------------------
> >> java.beans.beancontext.BeanContextServicesSupport.hasService(null) -------------------------- java.lang.NullPointerException
> >> java.beans.beancontext.BeanContextServicesSupport.removeBeanContextServicesListener(null) -------------------------- java.lang.NullPointerException
> >> java.beans.beancontext.BeanContextServicesSupport.serviceAvailable(null) -------------------------- java.lang.NullPointerException
> >> java.beans.beancontext.BeanContextServicesSupport.serviceRevoked(null) -------------------------- java.lang.NullPointerException
> >> java.beans.beancontext.BeanContextSupport.addAll(null) java.lang.NullPointerException java.lang.UnsupportedOperationException
> >> java.beans.beancontext.BeanContextSupport.getResource("", null) -------------------------- java.lang.NullPointerException
> >> java.beans.beancontext.BeanContextSupport.getResource(null, null) java.lang.IllegalArgumentException java.lang.NullPointerException
> >> java.beans.beancontext.BeanContextSupport.getResourceAsStream("", null) -------------------------- java.lang.NullPointerException
> >> java.beans.beancontext.BeanContextSupport.getResourceAsStream(null, null) java.lang.IllegalArgumentException java.lang.NullPointerException
> >> java.beans.beancontext.BeanContextSupport.vetoableChange(null) -------------------------- java.lang.NullPointerException
> >> java.beans.Beans.isInstanceOf(java.lang.Object, null) java.lang.NullPointerException --------------------------
> >> java.beans.Encoder.getPersistenceDelegate(null) java.lang.NullPointerException --------------------------
> >> java.beans.Encoder.setPersistenceDelegate(null, null) -------------------------- java.lang.NullPointerException
> >> java.beans.Encoder.writeExpression(null) -------------------------- java.lang.NullPointerException
> >> java.beans.FeatureDescriptor.setValue("", null) -------------------------- java.lang.NullPointerException
> >> java.beans.FeatureDescriptor.setValue(null, java.lang.Object) -------------------------- java.lang.NullPointerException
> >> java.beans.FeatureDescriptor.setValue(null, null) -------------------------- java.lang.NullPointerException
> >> java.beans.PropertyEditorManager.findEditor(null) -------------------------- java.lang.NullPointerException
> >> java.beans.PropertyEditorManager.registerEditor(null, null) -------------------------- java.lang.NullPointerException
> >> java.beans.SimpleBeanInfo.loadImage("") java.lang.NullPointerException --------------------------
> >> java.beans.SimpleBeanInfo.loadImage(null) java.lang.NullPointerException --------------------------
> >> java.io.ByteArrayOutputStream.toString("") java.nio.charset.IllegalCharsetNameException java.io.UnsupportedEncodingException
> >> java.io.ByteArrayOutputStream.write([B, 0, -1) java.lang.ArrayIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
> >> java.io.ByteArrayOutputStream.write([B, -1, 0) java.lang.ArrayIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
> >> java.io.ByteArrayOutputStream.write([B, -1, -1) java.lang.ArrayIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
> >> java.io.ByteArrayOutputStream.write(null, -1, 0) java.lang.NullPointerException java.lang.IndexOutOfBoundsException
> >> java.io.ByteArrayOutputStream.write(null, -1, -1) java.lang.NullPointerException java.lang.IndexOutOfBoundsException
> >> java.io.CharArrayWriter.write([C, 0, -1) java.lang.ArrayIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
> >> java.io.CharArrayWriter.write([C, -1, 0) java.lang.ArrayIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
> >> java.io.CharArrayWriter.write([C, -1, -1) java.lang.ArrayIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
> >> java.io.CharArrayWriter.write(null, -1, 0) java.lang.StringIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
> >> java.io.CharArrayWriter.write(null, -1, -1) java.lang.StringIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
> >> java.io.PipedInputStream.read([B, 0, -1) java.lang.ArrayIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
> >> java.io.PipedInputStream.read([B, -1, 0) java.lang.ArrayIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
> >> java.io.PipedInputStream.read([B, -1, -1) java.lang.ArrayIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
> >> java.io.PipedOutputStream.write([B, 0, 0) -------------------------- java.io.IOException
> >> java.io.PipedOutputStream.write([B, 0, -1) java.lang.ArrayIndexOutOfBoundsException java.io.IOException
> >> java.io.PipedOutputStream.write([B, -1, 0) java.lang.ArrayIndexOutOfBoundsException java.io.IOException
> >> java.io.PipedOutputStream.write([B, -1, -1) java.lang.ArrayIndexOutOfBoundsException java.io.IOException
> >> java.io.PipedOutputStream.write(null, 0, 0) java.lang.NullPointerException java.io.IOException
> >> java.io.PipedOutputStream.write(null, 0, -1) java.lang.NullPointerException java.io.IOException
> >> java.io.PipedOutputStream.write(null, -1, 0) java.lang.NullPointerException java.io.IOException
> >> java.io.PipedOutputStream.write(null, -1, -1) java.lang.NullPointerException java.io.IOException
> >> java.io.PipedReader.read([C, 0, -1) java.lang.ArrayIndexOutOfBoundsException java.io.IOException
> >> java.io.PipedReader.read([C, -1, 0) java.lang.ArrayIndexOutOfBoundsException java.io.IOException
> >> java.io.PipedReader.read([C, -1, -1) java.lang.ArrayIndexOutOfBoundsException java.io.IOException
> >> java.io.PipedReader.read(null, 0, 0) java.lang.NullPointerException java.io.IOException
> >> java.io.PipedReader.read(null, 0, -1) java.lang.NullPointerException java.io.IOException
> >> java.io.PipedReader.read(null, -1, 0) java.lang.ArrayIndexOutOfBoundsException java.io.IOException
> >> java.io.PipedReader.read(null, -1, -1) java.lang.ArrayIndexOutOfBoundsException java.io.IOException
> >> java.io.PipedWriter.write([C, 0, -1) java.lang.ArrayIndexOutOfBoundsException java.io.IOException
> >> java.io.PipedWriter.write([C, -1, 0) java.lang.ArrayIndexOutOfBoundsException java.io.IOException
> >> java.io.PipedWriter.write([C, -1, -1) java.lang.ArrayIndexOutOfBoundsException java.io.IOException
> >> java.io.PipedWriter.write(null, 0, 0) java.lang.NullPointerException java.io.IOException
> >> java.io.PipedWriter.write(null, 0, -1) java.lang.NullPointerException java.io.IOException
> >> java.io.PipedWriter.write(null, -1, 0) java.lang.ArrayIndexOutOfBoundsException java.io.IOException
> >> java.io.PipedWriter.write(null, -1, -1) java.lang.ArrayIndexOutOfBoundsException java.io.IOException
> >> java.io.StringWriter.write([C, 0, -1) java.lang.ArrayIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
> >> java.io.StringWriter.write([C, -1, 0) java.lang.ArrayIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
> >> java.io.StringWriter.write([C, -1, -1) java.lang.ArrayIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
> >> java.lang.SecurityManager.checkConnect("", -1) java.security.AccessControlException --------------------------
> >> java.lang.SecurityManager.checkListen(0) java.security.AccessControlException --------------------------
> >> java.lang.String.getBytes("") java.nio.charset.IllegalCharsetNameException java.io.UnsupportedEncodingException
> >> java.lang.String.getBytes(0, 0, null, 0) java.lang.NullPointerException --------------------------
> >> java.lang.String.getBytes(0, 0, null, -1) java.lang.NullPointerException --------------------------
> >> java.lang.String.getBytes(0, -1, null, 0) java.lang.NullPointerException java.lang.StringIndexOutOfBoundsException
> >> java.lang.String.getBytes(0, -1, null, -1) java.lang.NullPointerException java.lang.StringIndexOutOfBoundsException
> >> java.lang.String.getBytes(-1, 0, null, 0) java.lang.NullPointerException java.lang.StringIndexOutOfBoundsException
> >> java.lang.String.getBytes(-1, 0, null, -1) java.lang.NullPointerException java.lang.StringIndexOutOfBoundsException
> >> java.lang.String.getBytes(-1, -1, null, 0) java.lang.NullPointerException java.lang.StringIndexOutOfBoundsException
> >> java.lang.String.getBytes(-1, -1, null, -1) java.lang.NullPointerException java.lang.StringIndexOutOfBoundsException
> >> java.lang.String.replaceAll("", null) -------------------------- java.lang.NullPointerException
> >> java.lang.String.replaceFirst("", null) -------------------------- java.lang.NullPointerException
> >> java.lang.String.toLowerCase(null) -------------------------- java.lang.NullPointerException
> >> java.lang.String.valueOf(null) -------------------------- java.lang.NullPointerException
> >> java.lang.StringBuffer.append([C, 0, -1) java.lang.StringIndexOutOfBoundsException java.lang.ArrayIndexOutOfBoundsException
> >> java.lang.StringBuffer.append([C, -1, 0) java.lang.StringIndexOutOfBoundsException java.lang.ArrayIndexOutOfBoundsException
> >> java.lang.StringBuffer.append([C, -1, -1) java.lang.StringIndexOutOfBoundsException java.lang.ArrayIndexOutOfBoundsException
> >> java.lang.StringBuffer.append(null) -------------------------- java.lang.NullPointerException
> >> java.lang.StringBuffer.append(null, 0, 0) -------------------------- java.lang.NullPointerException
> >> java.lang.StringBuffer.append(null, 0, -1) java.lang.IndexOutOfBoundsException java.lang.NullPointerException
> >> java.lang.StringBuffer.append(null, -1, 0) java.lang.IndexOutOfBoundsException java.lang.NullPointerException
> >> java.lang.StringBuffer.append(null, -1, -1) java.lang.IndexOutOfBoundsException java.lang.NullPointerException
> >> java.lang.StringBuffer.appendCodePoint(-1) -------------------------- java.lang.IllegalArgumentException
> >> java.lang.StringBuffer.getChars(0, 0, [C, -1) java.lang.StringIndexOutOfBoundsException java.lang.ArrayIndexOutOfBoundsException
> >> java.lang.StringBuffer.getChars(0, -1, null, 0) java.lang.NullPointerException java.lang.StringIndexOutOfBoundsException
> >> java.lang.StringBuffer.getChars(0, -1, null, -1) java.lang.NullPointerException java.lang.StringIndexOutOfBoundsException
> >> java.lang.StringBuffer.getChars(-1, 0, null, 0) java.lang.NullPointerException java.lang.StringIndexOutOfBoundsException
> >> java.lang.StringBuffer.getChars(-1, 0, null, -1) java.lang.NullPointerException java.lang.StringIndexOutOfBoundsException
> >> java.lang.StringBuffer.getChars(-1, -1, null, 0) java.lang.NullPointerException java.lang.StringIndexOutOfBoundsException
> >> java.lang.StringBuffer.getChars(-1, -1, null, -1) java.lang.NullPointerException java.lang.StringIndexOutOfBoundsException
> >> java.lang.StringBuffer.insert(-1, ) java.lang.StringIndexOutOfBoundsException java.lang.ArrayIndexOutOfBoundsException
> >> java.lang.StringBuffer.offsetByCodePoints(0, 0) org.apache.harmony.luni.util.NotYetImplementedException --------------------------
> >> java.lang.StringBuffer.offsetByCodePoints(0, -1) org.apache.harmony.luni.util.NotYetImplementedException java.lang.IndexOutOfBoundsException
> >> java.lang.StringBuffer.offsetByCodePoints(-1, 0) org.apache.harmony.luni.util.NotYetImplementedException java.lang.IndexOutOfBoundsException
> >> java.lang.StringBuffer.offsetByCodePoints(-1, -1) org.apache.harmony.luni.util.NotYetImplementedException java.lang.IndexOutOfBoundsException
> >> java.lang.StringBuffer.setLength(-1) java.lang.IndexOutOfBoundsException java.lang.StringIndexOutOfBoundsException
> >> java.lang.StringBuilder.append([C, 0, -1) java.lang.StringIndexOutOfBoundsException java.lang.ArrayIndexOutOfBoundsException
> >> java.lang.StringBuilder.append([C, -1, 0) java.lang.StringIndexOutOfBoundsException java.lang.ArrayIndexOutOfBoundsException
> >> java.lang.StringBuilder.append([C, -1, -1) java.lang.StringIndexOutOfBoundsException java.lang.ArrayIndexOutOfBoundsException
> >> java.lang.StringBuilder.append(null, 0, -1) java.lang.StringIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
> >> java.lang.StringBuilder.append(null, -1, 0) java.lang.StringIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
> >> java.lang.StringBuilder.append(null, -1, -1) java.lang.StringIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
> >> java.lang.StringBuilder.appendCodePoint(0) org.apache.harmony.luni.util.NotYetImplementedException --------------------------
> >> java.lang.StringBuilder.appendCodePoint(-1) org.apache.harmony.luni.util.NotYetImplementedException java.lang.IllegalArgumentException
> >> java.lang.StringBuilder.insert(0, null, 0, -1) java.lang.StringIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
> >> java.lang.StringBuilder.insert(0, null, -1, 0) java.lang.StringIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
> >> java.lang.StringBuilder.insert(0, null, -1, -1) java.lang.StringIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
> >> java.lang.StringBuilder.insert(-1, ) java.lang.StringIndexOutOfBoundsException java.lang.ArrayIndexOutOfBoundsException
> >> java.net.DatagramSocket.bind(null) java.net.BindException java.net.SocketException
> >> java.net.MulticastSocket.setInterface(null) java.lang.NullPointerException java.net.SocketException
> >> java.net.URLDecoder.decode("", "") -------------------------- java.io.UnsupportedEncodingException
> >> java.security.cert.X509CertSelector.addPathToName(0, [B) org.apache.harmony.security.asn1.ASN1Exception java.io.IOException
> >> java.security.cert.X509CertSelector.addPathToName(-1, null) java.io.IOException java.lang.NullPointerException
> >> java.security.cert.X509CertSelector.addSubjectAlternativeName(0, [B) org.apache.harmony.security.asn1.ASN1Exception java.io.IOException
> >> java.security.cert.X509CertSelector.addSubjectAlternativeName(-1, null) java.io.IOException java.lang.NullPointerException
> >> java.security.cert.X509CertSelector.setNameConstraints([B) org.apache.harmony.security.asn1.ASN1Exception java.io.IOException
> >> java.security.cert.X509CertSelector.setSubjectPublicKey([B) org.apache.harmony.security.asn1.ASN1Exception java.io.IOException
> >> java.security.cert.X509CertSelector.setSubjectPublicKeyAlgID("") java.lang.StringIndexOutOfBoundsException java.lang.NumberFormatException
> >> java.security.cert.X509CRLSelector.addIssuer(null) -------------------------- java.lang.NullPointerException
> >> java.security.cert.X509CRLSelector.addIssuerName([B) java.lang.IllegalArgumentException java.io.IOException
> >> java.security.cert.X509CRLSelector.addIssuerName(null) java.lang.IllegalArgumentException java.lang.NullPointerException
> >> java.security.Permissions.implies(null) -------------------------- java.lang.NullPointerException
> >> java.security.SecureRandom.generateSeed(-1) -------------------------- java.lang.NegativeArraySizeException
> >> java.security.SecureRandom.getSeed(-1) -------------------------- java.lang.NegativeArraySizeException
> >> java.text.DateFormatSymbols.setLocalPatternChars(null) -------------------------- java.lang.NullPointerException
> >> java.text.DecimalFormat.formatToCharacterIterator(null) java.lang.IllegalArgumentException java.lang.NullPointerException
> >> java.text.SimpleDateFormat.formatToCharacterIterator(null) java.lang.IllegalArgumentException java.lang.NullPointerException
> >> java.util.ArrayList.addAll(-1, null) java.lang.NullPointerException java.lang.IndexOutOfBoundsException
> >> java.util.ArrayList.get(-1) java.lang.IndexOutOfBoundsException java.lang.ArrayIndexOutOfBoundsException
> >> java.util.ArrayList.remove(-1) java.lang.IndexOutOfBoundsException java.lang.ArrayIndexOutOfBoundsException
> >> java.util.ArrayList.set(-1, java.lang.Object) java.lang.IndexOutOfBoundsException java.lang.ArrayIndexOutOfBoundsException
> >> java.util.ArrayList.set(-1, null) java.lang.IndexOutOfBoundsException java.lang.ArrayIndexOutOfBoundsException
> >> java.util.Date.parse(null) java.lang.NullPointerException java.lang.IllegalArgumentException
> >> java.util.jar.Attributes.putAll(null) java.lang.NullPointerException java.lang.ClassCastException
> >> java.util.LinkedList.addAll(-1, null) java.lang.NullPointerException java.lang.IndexOutOfBoundsException
> >> java.util.TreeMap.containsKey(java.lang.Object) java.lang.ClassCastException --------------------------
> >> java.util.TreeMap.get(java.lang.Object) java.lang.ClassCastException --------------------------
> >> java.util.TreeMap.put(java.lang.Object, java.lang.Object) java.lang.ClassCastException --------------------------
> >> java.util.TreeMap.put(java.lang.Object, null) java.lang.ClassCastException --------------------------
> >> java.util.TreeMap.remove(java.lang.Object) java.lang.ClassCastException --------------------------
> >> java.util.TreeSet.add(java.lang.Object) java.lang.ClassCastException --------------------------
> >> java.util.TreeSet.contains(java.lang.Object) java.lang.ClassCastException --------------------------
> >> java.util.TreeSet.remove(java.lang.Object) java.lang.ClassCastException --------------------------
> >> java.util.Vector.lastIndexOf(java.lang.Object, 0) java.lang.ArrayIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
> >> java.util.Vector.lastIndexOf(null, 0) java.lang.ArrayIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
> >> java.util.zip.Inflater.inflate([B) java.util.zip.DataFormatException --------------------------
> >> java.util.zip.Inflater.inflate([B, 0, 0) java.util.zip.DataFormatException --------------------------
> >> javax.naming.InitialContext.composeName("", null) javax.naming.InvalidNameException --------------------------
> >> javax.naming.InitialContext.composeName(null, "") javax.naming.InvalidNameException --------------------------
> >> javax.naming.InitialContext.composeName(null, null) javax.naming.InvalidNameException --------------------------
> >> javax.naming.ldap.InitialLdapContext.extendedOperation(null) javax.naming.NotContextException javax.naming.NoInitialContextException
> >> javax.naming.ldap.InitialLdapContext.newInstance([Ljavax.naming.ldap.Control;) javax.naming.NotContextException javax.naming.NoInitialContextException
> >> javax.naming.ldap.InitialLdapContext.newInstance(null) javax.naming.NotContextException javax.naming.NoInitialContextException
> >> javax.naming.ldap.InitialLdapContext.reconnect([Ljavax.naming.ldap.Control;) javax.naming.NotContextException javax.naming.NoInitialContextException
> >> javax.naming.ldap.InitialLdapContext.reconnect(null) javax.naming.NotContextException javax.naming.NoInitialContextException
> >> javax.naming.ldap.InitialLdapContext.setRequestControls([Ljavax.naming.ldap.Control;) javax.naming.NotContextException javax.naming.NoInitialContextException
> >> javax.naming.ldap.InitialLdapContext.setRequestControls(null) javax.naming.NotContextException javax.naming.NoInitialContextException
> >> javax.xml.transform.stream.StreamResult.setSystemId(null) java.lang.NullPointerException --------------------------
> >> javax.xml.transform.stream.StreamSource.setSystemId(null) java.lang.NullPointerException --------------------------
> >>
> >>
> >>
> >> ------------------------------------------------------------------------
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
> --
>
> Tim Ellison (t.p.ellison@gmail.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
Re: matching reference implementation exception behaviour
Posted by Tim Ellison <t....@gmail.com>.
Alex Orlov 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?
Probably makes sense to group them into either one type (where there are
a few issues for a given type) or one module rather than all together,
since I'm assuming that would be too big when you have included the
proposed fix and test case (hint, hint) ;-)
Regards,
Tim
> Thanks,
> Alex Orlov.
> Intel Middleware products Division
>
> On 3/24/06, Geir Magnusson Jr <ge...@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 <ma...@googlemail.com>
>>>> IBM Java Technology Centre, UK.
>>>>
>>>>
>>>
>>
>> ------------------------------------------------------------------------
>>
>> METHOD Harmony BEA
>>
>> java.beans.beancontext.BeanContextServicesSupport.getCurrentServiceSelectors(null) java.lang.NullPointerException --------------------------
>> java.beans.beancontext.BeanContextServicesSupport.hasService(null) -------------------------- java.lang.NullPointerException
>> java.beans.beancontext.BeanContextServicesSupport.removeBeanContextServicesListener(null) -------------------------- java.lang.NullPointerException
>> java.beans.beancontext.BeanContextServicesSupport.serviceAvailable(null) -------------------------- java.lang.NullPointerException
>> java.beans.beancontext.BeanContextServicesSupport.serviceRevoked(null) -------------------------- java.lang.NullPointerException
>> java.beans.beancontext.BeanContextSupport.addAll(null) java.lang.NullPointerException java.lang.UnsupportedOperationException
>> java.beans.beancontext.BeanContextSupport.getResource("", null) -------------------------- java.lang.NullPointerException
>> java.beans.beancontext.BeanContextSupport.getResource(null, null) java.lang.IllegalArgumentException java.lang.NullPointerException
>> java.beans.beancontext.BeanContextSupport.getResourceAsStream("", null) -------------------------- java.lang.NullPointerException
>> java.beans.beancontext.BeanContextSupport.getResourceAsStream(null, null) java.lang.IllegalArgumentException java.lang.NullPointerException
>> java.beans.beancontext.BeanContextSupport.vetoableChange(null) -------------------------- java.lang.NullPointerException
>> java.beans.Beans.isInstanceOf(java.lang.Object, null) java.lang.NullPointerException --------------------------
>> java.beans.Encoder.getPersistenceDelegate(null) java.lang.NullPointerException --------------------------
>> java.beans.Encoder.setPersistenceDelegate(null, null) -------------------------- java.lang.NullPointerException
>> java.beans.Encoder.writeExpression(null) -------------------------- java.lang.NullPointerException
>> java.beans.FeatureDescriptor.setValue("", null) -------------------------- java.lang.NullPointerException
>> java.beans.FeatureDescriptor.setValue(null, java.lang.Object) -------------------------- java.lang.NullPointerException
>> java.beans.FeatureDescriptor.setValue(null, null) -------------------------- java.lang.NullPointerException
>> java.beans.PropertyEditorManager.findEditor(null) -------------------------- java.lang.NullPointerException
>> java.beans.PropertyEditorManager.registerEditor(null, null) -------------------------- java.lang.NullPointerException
>> java.beans.SimpleBeanInfo.loadImage("") java.lang.NullPointerException --------------------------
>> java.beans.SimpleBeanInfo.loadImage(null) java.lang.NullPointerException --------------------------
>> java.io.ByteArrayOutputStream.toString("") java.nio.charset.IllegalCharsetNameException java.io.UnsupportedEncodingException
>> java.io.ByteArrayOutputStream.write([B, 0, -1) java.lang.ArrayIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
>> java.io.ByteArrayOutputStream.write([B, -1, 0) java.lang.ArrayIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
>> java.io.ByteArrayOutputStream.write([B, -1, -1) java.lang.ArrayIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
>> java.io.ByteArrayOutputStream.write(null, -1, 0) java.lang.NullPointerException java.lang.IndexOutOfBoundsException
>> java.io.ByteArrayOutputStream.write(null, -1, -1) java.lang.NullPointerException java.lang.IndexOutOfBoundsException
>> java.io.CharArrayWriter.write([C, 0, -1) java.lang.ArrayIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
>> java.io.CharArrayWriter.write([C, -1, 0) java.lang.ArrayIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
>> java.io.CharArrayWriter.write([C, -1, -1) java.lang.ArrayIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
>> java.io.CharArrayWriter.write(null, -1, 0) java.lang.StringIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
>> java.io.CharArrayWriter.write(null, -1, -1) java.lang.StringIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
>> java.io.PipedInputStream.read([B, 0, -1) java.lang.ArrayIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
>> java.io.PipedInputStream.read([B, -1, 0) java.lang.ArrayIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
>> java.io.PipedInputStream.read([B, -1, -1) java.lang.ArrayIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
>> java.io.PipedOutputStream.write([B, 0, 0) -------------------------- java.io.IOException
>> java.io.PipedOutputStream.write([B, 0, -1) java.lang.ArrayIndexOutOfBoundsException java.io.IOException
>> java.io.PipedOutputStream.write([B, -1, 0) java.lang.ArrayIndexOutOfBoundsException java.io.IOException
>> java.io.PipedOutputStream.write([B, -1, -1) java.lang.ArrayIndexOutOfBoundsException java.io.IOException
>> java.io.PipedOutputStream.write(null, 0, 0) java.lang.NullPointerException java.io.IOException
>> java.io.PipedOutputStream.write(null, 0, -1) java.lang.NullPointerException java.io.IOException
>> java.io.PipedOutputStream.write(null, -1, 0) java.lang.NullPointerException java.io.IOException
>> java.io.PipedOutputStream.write(null, -1, -1) java.lang.NullPointerException java.io.IOException
>> java.io.PipedReader.read([C, 0, -1) java.lang.ArrayIndexOutOfBoundsException java.io.IOException
>> java.io.PipedReader.read([C, -1, 0) java.lang.ArrayIndexOutOfBoundsException java.io.IOException
>> java.io.PipedReader.read([C, -1, -1) java.lang.ArrayIndexOutOfBoundsException java.io.IOException
>> java.io.PipedReader.read(null, 0, 0) java.lang.NullPointerException java.io.IOException
>> java.io.PipedReader.read(null, 0, -1) java.lang.NullPointerException java.io.IOException
>> java.io.PipedReader.read(null, -1, 0) java.lang.ArrayIndexOutOfBoundsException java.io.IOException
>> java.io.PipedReader.read(null, -1, -1) java.lang.ArrayIndexOutOfBoundsException java.io.IOException
>> java.io.PipedWriter.write([C, 0, -1) java.lang.ArrayIndexOutOfBoundsException java.io.IOException
>> java.io.PipedWriter.write([C, -1, 0) java.lang.ArrayIndexOutOfBoundsException java.io.IOException
>> java.io.PipedWriter.write([C, -1, -1) java.lang.ArrayIndexOutOfBoundsException java.io.IOException
>> java.io.PipedWriter.write(null, 0, 0) java.lang.NullPointerException java.io.IOException
>> java.io.PipedWriter.write(null, 0, -1) java.lang.NullPointerException java.io.IOException
>> java.io.PipedWriter.write(null, -1, 0) java.lang.ArrayIndexOutOfBoundsException java.io.IOException
>> java.io.PipedWriter.write(null, -1, -1) java.lang.ArrayIndexOutOfBoundsException java.io.IOException
>> java.io.StringWriter.write([C, 0, -1) java.lang.ArrayIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
>> java.io.StringWriter.write([C, -1, 0) java.lang.ArrayIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
>> java.io.StringWriter.write([C, -1, -1) java.lang.ArrayIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
>> java.lang.SecurityManager.checkConnect("", -1) java.security.AccessControlException --------------------------
>> java.lang.SecurityManager.checkListen(0) java.security.AccessControlException --------------------------
>> java.lang.String.getBytes("") java.nio.charset.IllegalCharsetNameException java.io.UnsupportedEncodingException
>> java.lang.String.getBytes(0, 0, null, 0) java.lang.NullPointerException --------------------------
>> java.lang.String.getBytes(0, 0, null, -1) java.lang.NullPointerException --------------------------
>> java.lang.String.getBytes(0, -1, null, 0) java.lang.NullPointerException java.lang.StringIndexOutOfBoundsException
>> java.lang.String.getBytes(0, -1, null, -1) java.lang.NullPointerException java.lang.StringIndexOutOfBoundsException
>> java.lang.String.getBytes(-1, 0, null, 0) java.lang.NullPointerException java.lang.StringIndexOutOfBoundsException
>> java.lang.String.getBytes(-1, 0, null, -1) java.lang.NullPointerException java.lang.StringIndexOutOfBoundsException
>> java.lang.String.getBytes(-1, -1, null, 0) java.lang.NullPointerException java.lang.StringIndexOutOfBoundsException
>> java.lang.String.getBytes(-1, -1, null, -1) java.lang.NullPointerException java.lang.StringIndexOutOfBoundsException
>> java.lang.String.replaceAll("", null) -------------------------- java.lang.NullPointerException
>> java.lang.String.replaceFirst("", null) -------------------------- java.lang.NullPointerException
>> java.lang.String.toLowerCase(null) -------------------------- java.lang.NullPointerException
>> java.lang.String.valueOf(null) -------------------------- java.lang.NullPointerException
>> java.lang.StringBuffer.append([C, 0, -1) java.lang.StringIndexOutOfBoundsException java.lang.ArrayIndexOutOfBoundsException
>> java.lang.StringBuffer.append([C, -1, 0) java.lang.StringIndexOutOfBoundsException java.lang.ArrayIndexOutOfBoundsException
>> java.lang.StringBuffer.append([C, -1, -1) java.lang.StringIndexOutOfBoundsException java.lang.ArrayIndexOutOfBoundsException
>> java.lang.StringBuffer.append(null) -------------------------- java.lang.NullPointerException
>> java.lang.StringBuffer.append(null, 0, 0) -------------------------- java.lang.NullPointerException
>> java.lang.StringBuffer.append(null, 0, -1) java.lang.IndexOutOfBoundsException java.lang.NullPointerException
>> java.lang.StringBuffer.append(null, -1, 0) java.lang.IndexOutOfBoundsException java.lang.NullPointerException
>> java.lang.StringBuffer.append(null, -1, -1) java.lang.IndexOutOfBoundsException java.lang.NullPointerException
>> java.lang.StringBuffer.appendCodePoint(-1) -------------------------- java.lang.IllegalArgumentException
>> java.lang.StringBuffer.getChars(0, 0, [C, -1) java.lang.StringIndexOutOfBoundsException java.lang.ArrayIndexOutOfBoundsException
>> java.lang.StringBuffer.getChars(0, -1, null, 0) java.lang.NullPointerException java.lang.StringIndexOutOfBoundsException
>> java.lang.StringBuffer.getChars(0, -1, null, -1) java.lang.NullPointerException java.lang.StringIndexOutOfBoundsException
>> java.lang.StringBuffer.getChars(-1, 0, null, 0) java.lang.NullPointerException java.lang.StringIndexOutOfBoundsException
>> java.lang.StringBuffer.getChars(-1, 0, null, -1) java.lang.NullPointerException java.lang.StringIndexOutOfBoundsException
>> java.lang.StringBuffer.getChars(-1, -1, null, 0) java.lang.NullPointerException java.lang.StringIndexOutOfBoundsException
>> java.lang.StringBuffer.getChars(-1, -1, null, -1) java.lang.NullPointerException java.lang.StringIndexOutOfBoundsException
>> java.lang.StringBuffer.insert(-1, ) java.lang.StringIndexOutOfBoundsException java.lang.ArrayIndexOutOfBoundsException
>> java.lang.StringBuffer.offsetByCodePoints(0, 0) org.apache.harmony.luni.util.NotYetImplementedException --------------------------
>> java.lang.StringBuffer.offsetByCodePoints(0, -1) org.apache.harmony.luni.util.NotYetImplementedException java.lang.IndexOutOfBoundsException
>> java.lang.StringBuffer.offsetByCodePoints(-1, 0) org.apache.harmony.luni.util.NotYetImplementedException java.lang.IndexOutOfBoundsException
>> java.lang.StringBuffer.offsetByCodePoints(-1, -1) org.apache.harmony.luni.util.NotYetImplementedException java.lang.IndexOutOfBoundsException
>> java.lang.StringBuffer.setLength(-1) java.lang.IndexOutOfBoundsException java.lang.StringIndexOutOfBoundsException
>> java.lang.StringBuilder.append([C, 0, -1) java.lang.StringIndexOutOfBoundsException java.lang.ArrayIndexOutOfBoundsException
>> java.lang.StringBuilder.append([C, -1, 0) java.lang.StringIndexOutOfBoundsException java.lang.ArrayIndexOutOfBoundsException
>> java.lang.StringBuilder.append([C, -1, -1) java.lang.StringIndexOutOfBoundsException java.lang.ArrayIndexOutOfBoundsException
>> java.lang.StringBuilder.append(null, 0, -1) java.lang.StringIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
>> java.lang.StringBuilder.append(null, -1, 0) java.lang.StringIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
>> java.lang.StringBuilder.append(null, -1, -1) java.lang.StringIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
>> java.lang.StringBuilder.appendCodePoint(0) org.apache.harmony.luni.util.NotYetImplementedException --------------------------
>> java.lang.StringBuilder.appendCodePoint(-1) org.apache.harmony.luni.util.NotYetImplementedException java.lang.IllegalArgumentException
>> java.lang.StringBuilder.insert(0, null, 0, -1) java.lang.StringIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
>> java.lang.StringBuilder.insert(0, null, -1, 0) java.lang.StringIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
>> java.lang.StringBuilder.insert(0, null, -1, -1) java.lang.StringIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
>> java.lang.StringBuilder.insert(-1, ) java.lang.StringIndexOutOfBoundsException java.lang.ArrayIndexOutOfBoundsException
>> java.net.DatagramSocket.bind(null) java.net.BindException java.net.SocketException
>> java.net.MulticastSocket.setInterface(null) java.lang.NullPointerException java.net.SocketException
>> java.net.URLDecoder.decode("", "") -------------------------- java.io.UnsupportedEncodingException
>> java.security.cert.X509CertSelector.addPathToName(0, [B) org.apache.harmony.security.asn1.ASN1Exception java.io.IOException
>> java.security.cert.X509CertSelector.addPathToName(-1, null) java.io.IOException java.lang.NullPointerException
>> java.security.cert.X509CertSelector.addSubjectAlternativeName(0, [B) org.apache.harmony.security.asn1.ASN1Exception java.io.IOException
>> java.security.cert.X509CertSelector.addSubjectAlternativeName(-1, null) java.io.IOException java.lang.NullPointerException
>> java.security.cert.X509CertSelector.setNameConstraints([B) org.apache.harmony.security.asn1.ASN1Exception java.io.IOException
>> java.security.cert.X509CertSelector.setSubjectPublicKey([B) org.apache.harmony.security.asn1.ASN1Exception java.io.IOException
>> java.security.cert.X509CertSelector.setSubjectPublicKeyAlgID("") java.lang.StringIndexOutOfBoundsException java.lang.NumberFormatException
>> java.security.cert.X509CRLSelector.addIssuer(null) -------------------------- java.lang.NullPointerException
>> java.security.cert.X509CRLSelector.addIssuerName([B) java.lang.IllegalArgumentException java.io.IOException
>> java.security.cert.X509CRLSelector.addIssuerName(null) java.lang.IllegalArgumentException java.lang.NullPointerException
>> java.security.Permissions.implies(null) -------------------------- java.lang.NullPointerException
>> java.security.SecureRandom.generateSeed(-1) -------------------------- java.lang.NegativeArraySizeException
>> java.security.SecureRandom.getSeed(-1) -------------------------- java.lang.NegativeArraySizeException
>> java.text.DateFormatSymbols.setLocalPatternChars(null) -------------------------- java.lang.NullPointerException
>> java.text.DecimalFormat.formatToCharacterIterator(null) java.lang.IllegalArgumentException java.lang.NullPointerException
>> java.text.SimpleDateFormat.formatToCharacterIterator(null) java.lang.IllegalArgumentException java.lang.NullPointerException
>> java.util.ArrayList.addAll(-1, null) java.lang.NullPointerException java.lang.IndexOutOfBoundsException
>> java.util.ArrayList.get(-1) java.lang.IndexOutOfBoundsException java.lang.ArrayIndexOutOfBoundsException
>> java.util.ArrayList.remove(-1) java.lang.IndexOutOfBoundsException java.lang.ArrayIndexOutOfBoundsException
>> java.util.ArrayList.set(-1, java.lang.Object) java.lang.IndexOutOfBoundsException java.lang.ArrayIndexOutOfBoundsException
>> java.util.ArrayList.set(-1, null) java.lang.IndexOutOfBoundsException java.lang.ArrayIndexOutOfBoundsException
>> java.util.Date.parse(null) java.lang.NullPointerException java.lang.IllegalArgumentException
>> java.util.jar.Attributes.putAll(null) java.lang.NullPointerException java.lang.ClassCastException
>> java.util.LinkedList.addAll(-1, null) java.lang.NullPointerException java.lang.IndexOutOfBoundsException
>> java.util.TreeMap.containsKey(java.lang.Object) java.lang.ClassCastException --------------------------
>> java.util.TreeMap.get(java.lang.Object) java.lang.ClassCastException --------------------------
>> java.util.TreeMap.put(java.lang.Object, java.lang.Object) java.lang.ClassCastException --------------------------
>> java.util.TreeMap.put(java.lang.Object, null) java.lang.ClassCastException --------------------------
>> java.util.TreeMap.remove(java.lang.Object) java.lang.ClassCastException --------------------------
>> java.util.TreeSet.add(java.lang.Object) java.lang.ClassCastException --------------------------
>> java.util.TreeSet.contains(java.lang.Object) java.lang.ClassCastException --------------------------
>> java.util.TreeSet.remove(java.lang.Object) java.lang.ClassCastException --------------------------
>> java.util.Vector.lastIndexOf(java.lang.Object, 0) java.lang.ArrayIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
>> java.util.Vector.lastIndexOf(null, 0) java.lang.ArrayIndexOutOfBoundsException java.lang.IndexOutOfBoundsException
>> java.util.zip.Inflater.inflate([B) java.util.zip.DataFormatException --------------------------
>> java.util.zip.Inflater.inflate([B, 0, 0) java.util.zip.DataFormatException --------------------------
>> javax.naming.InitialContext.composeName("", null) javax.naming.InvalidNameException --------------------------
>> javax.naming.InitialContext.composeName(null, "") javax.naming.InvalidNameException --------------------------
>> javax.naming.InitialContext.composeName(null, null) javax.naming.InvalidNameException --------------------------
>> javax.naming.ldap.InitialLdapContext.extendedOperation(null) javax.naming.NotContextException javax.naming.NoInitialContextException
>> javax.naming.ldap.InitialLdapContext.newInstance([Ljavax.naming.ldap.Control;) javax.naming.NotContextException javax.naming.NoInitialContextException
>> javax.naming.ldap.InitialLdapContext.newInstance(null) javax.naming.NotContextException javax.naming.NoInitialContextException
>> javax.naming.ldap.InitialLdapContext.reconnect([Ljavax.naming.ldap.Control;) javax.naming.NotContextException javax.naming.NoInitialContextException
>> javax.naming.ldap.InitialLdapContext.reconnect(null) javax.naming.NotContextException javax.naming.NoInitialContextException
>> javax.naming.ldap.InitialLdapContext.setRequestControls([Ljavax.naming.ldap.Control;) javax.naming.NotContextException javax.naming.NoInitialContextException
>> javax.naming.ldap.InitialLdapContext.setRequestControls(null) javax.naming.NotContextException javax.naming.NoInitialContextException
>> javax.xml.transform.stream.StreamResult.setSystemId(null) java.lang.NullPointerException --------------------------
>> javax.xml.transform.stream.StreamSource.setSystemId(null) java.lang.NullPointerException --------------------------
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> ---------------------------------------------------------------------
>> 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
--
Tim Ellison (t.p.ellison@gmail.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
Re: matching reference implementation exception behaviour
Posted by Alex Orlov <am...@gmail.com>.
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 <ge...@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 <ma...@googlemail.com>
> >> IBM Java Technology Centre, UK.
> >>
> >>
> >
> >
>
Re: matching reference implementation exception behaviour
Posted by Geir Magnusson Jr <ge...@pobox.com>.
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 <ma...@googlemail.com>
>> IBM Java Technology Centre, UK.
>>
>>
>
>
Re: matching reference implementation exception behaviour
Posted by George Harley <ge...@googlemail.com>.
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.
And if that wasn't the consensus then it should have been ;-)
Best regards,
George
> Regards,
> Mark.
>
> --
> Mark Hindess <ma...@googlemail.com>
> IBM Java Technology Centre, UK.
>
>