You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mikhail Loenko <ml...@gmail.com> on 2006/04/24 08:48:45 UTC
[classlib] matching RI exceptions -- are we required to have this type of compatibility?
Look at HARMONY-387.
Example:
1) java.io.ByteArrayOutputStream.write(byte[] b , int off, int len):
Harmony throws ArrayIndexOutOfBoundsException when off<0 or/and len
<0, while RI throws IndexOutOfBoundsException.
Specification mentions neither ArrayIndexOutOfBoundsException nor
IndexOutOfBoundsException.
Actually ArrayIndexOutOfBoundsException is a sub class of
IndexOutOfBoundsException.
So the statement "both Harmony and RI throw IndexOutOfBoundsException" is
true.
But do we have to throw exactly those exceptions that are thrown by RI?
Can we throw
o.a.h.VMRisenNPE that extends NullPointerException?
What if they throw kind of
sun.internal.SunFavoriteSubClassOfNullPointerException ?
Thanks,
Mikhail
---------------------------------------------------------------------
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: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
Posted by Anton Avtamonov <an...@gmail.com>.
On 4/25/06, Jimmy, Jing Lv <fi...@gmail.com> wrote:
<SNIP>
> For the example 1) I mean the spec usually merge several exceptions into
> one parent exception. In this situation, commonly RI throws child
> exception itself, although it is hard to tell what RI exactly throw in
> some special situation.
> And I think we are not "improving" the spec if we throw child
> exceptions, it is just convention or something writing "throws
> IOException" instead of writing "throws connectionException,
> UnknownHostException". We do follow spec if we throw child exception.
>
> > The idea behind the question is: why not just copy RI in this case
> > (conforming Tim's guidelines)?
> >
>
> Yes,I firmly agree with Tim's guidelines. We should first follow spec
> and then RI. In this case, we still follow the spec, right? :)
Absolutely!
The question was: why we decided to throw sub-classing exceptions. If
the answer is: "because RI does" I completely support such decision
(which completely complies Tim's guidelines).
--
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: [classlib] matching RI exceptions -- are we required to have
this type of compatibility?
Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
Anton Avtamonov wrote:
> On 4/25/06, Dmitry M. Kononov <dm...@gmail.com> wrote:
>> On 4/25/06, Tim Ellison <t....@gmail.com> wrote:
>>> Jimmy, Jing Lv wrote:
>>>> I agree.
>>>> But there are at least two exceptional situation:
>>>> 1) several exceptions throws from one method, which extend one parent
>>>> class, e.g. ConnectionException and UnknownHostException, javadoc writes
>>>> "throws IOException" rather than "throws
>>>> ConnectionException,UnknownHostException". And in implementation, we
>>>> shall throw them out directly instead of
>>>> try{...
>>>> }catch(UnknownHostException e){
>>>> throw new IOException();
>>>> }
>>>> catch(ConnectionException e){
>>>> throw new IOException();
>>>> }
>>>> right? :)
>>> +1, and other instances where super-types or super-interfaces declare
>>> compatible throws clauses that are implemented in subclasses that throw
>>> more specific subtypes. I do not agree that we should be bound to throw
>>> and exception of the identical type as the declaration.
>> If we want to follow the spec and if we want to restrain ourself from
>> "improving" the spec, I think we really need to throw IOException. If
>> this exception can be caused by different ways we apparently have to
>> throw IOException with an appropriate cause.
>
>>>From the general perspective, in the example above re-throwing
> IOException looks quite ugly. Besides, it hides some important
> information (since Java uses exception sub-classing to represent the
> particular type of problem). However we are not free with design, I
> think. Could someone please remind me an idea: for the example above
> do we mean that the spec states IOException and RI throws exactly
> IOException (I traversed the thread, but still not sure what was
> meant)?
For the example 1) I mean the spec usually merge several exceptions into
one parent exception. In this situation, commonly RI throws child
exception itself, although it is hard to tell what RI exactly throw in
some special situation.
And I think we are not "improving" the spec if we throw child
exceptions, it is just convention or something writing "throws
IOException" instead of writing "throws connectionException,
UnknownHostException". We do follow spec if we throw child exception.
> The idea behind the question is: why not just copy RI in this case
> (conforming Tim's guidelines)?
>
Yes,I firmly agree with Tim's guidelines. We should first follow spec
and then RI. In this case, we still follow the spec, right? :)
> --
> 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
>
>
--
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: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
Posted by Anton Avtamonov <an...@gmail.com>.
On 4/25/06, Dmitry M. Kononov <dm...@gmail.com> wrote:
> On 4/25/06, Tim Ellison <t....@gmail.com> wrote:
> > Jimmy, Jing Lv wrote:
> > > I agree.
> > > But there are at least two exceptional situation:
> > > 1) several exceptions throws from one method, which extend one parent
> > > class, e.g. ConnectionException and UnknownHostException, javadoc writes
> > > "throws IOException" rather than "throws
> > > ConnectionException,UnknownHostException". And in implementation, we
> > > shall throw them out directly instead of
> > > try{...
> > > }catch(UnknownHostException e){
> > > throw new IOException();
> > > }
> > > catch(ConnectionException e){
> > > throw new IOException();
> > > }
> > > right? :)
> >
> > +1, and other instances where super-types or super-interfaces declare
> > compatible throws clauses that are implemented in subclasses that throw
> > more specific subtypes. I do not agree that we should be bound to throw
> > and exception of the identical type as the declaration.
>
> If we want to follow the spec and if we want to restrain ourself from
> "improving" the spec, I think we really need to throw IOException. If
> this exception can be caused by different ways we apparently have to
> throw IOException with an appropriate cause.
>From the general perspective, in the example above re-throwing
IOException looks quite ugly. Besides, it hides some important
information (since Java uses exception sub-classing to represent the
particular type of problem). However we are not free with design, I
think. Could someone please remind me an idea: for the example above
do we mean that the spec states IOException and RI throws exactly
IOException (I traversed the thread, but still not sure what was
meant)?
The idea behind the question is: why not just copy RI in this case
(conforming Tim's guidelines)?
--
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: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
Posted by "Dmitry M. Kononov" <dm...@gmail.com>.
On 4/25/06, Tim Ellison <t....@gmail.com> wrote:
> Jimmy, Jing Lv wrote:
> > I agree.
> > But there are at least two exceptional situation:
> > 1) several exceptions throws from one method, which extend one parent
> > class, e.g. ConnectionException and UnknownHostException, javadoc writes
> > "throws IOException" rather than "throws
> > ConnectionException,UnknownHostException". And in implementation, we
> > shall throw them out directly instead of
> > try{...
> > }catch(UnknownHostException e){
> > throw new IOException();
> > }
> > catch(ConnectionException e){
> > throw new IOException();
> > }
> > right? :)
>
> +1, and other instances where super-types or super-interfaces declare
> compatible throws clauses that are implemented in subclasses that throw
> more specific subtypes. I do not agree that we should be bound to throw
> and exception of the identical type as the declaration.
If we want to follow the spec and if we want to restrain ourself from
"improving" the spec, I think we really need to throw IOException. If
this exception can be caused by different ways we apparently have to
throw IOException with an appropriate cause.
Thanks.
--
Dmitry M. Kononov
Intel Managed Runtime 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: [classlib] matching RI exceptions -- are we required to have
this type of compatibility?
Posted by Tim Ellison <t....@gmail.com>.
Jimmy, Jing Lv wrote:
>> Geir Magnusson Jr wrote:
>>
>>
>> Vladimir Gorr wrote:
>>> Mikhail,
>>>
>>> I also thought about this scenario. However, if any TCK tests will
>>> fail due
>>> to this reason
>>> we cannot certify our product. Nobody will talk about the invalidity
>>> of TCK.
>>> Most likely we will update our sources.
>>
>> 1) I hadn't thought about this before, but it seems much cleaner to
>> throw A (rather than B extends A) if the spec says to throw A.
>>
> I agree.
> But there are at least two exceptional situation:
> 1) several exceptions throws from one method, which extend one parent
> class, e.g. ConnectionException and UnknownHostException, javadoc writes
> "throws IOException" rather than "throws
> ConnectionException,UnknownHostException". And in implementation, we
> shall throw them out directly instead of
> try{...
> }catch(UnknownHostException e){
> throw new IOException();
> }
> catch(ConnectionException e){
> throw new IOException();
> }
> right? :)
+1, and other instances where super-types or super-interfaces declare
compatible throws clauses that are implemented in subclasses that throw
more specific subtypes. I do not agree that we should be bound to throw
and exception of the identical type as the declaration.
> 2) and we may find some javadoc as "...then an unspecified error is
> thrown." For an example, in java.util.jar.Pack200.newPacker(). We can do
> nothing to meet such compatibility.
You can throw any Error to comply with that specification!
Regards,
Tim
> In summary, I think we shall follow doc in throwing exception; but if we
> find it inconvenient indeed or even impossible, let it be. :)
>
>> 2) You can challenge TCK tests and have them eliminated. We've done
>> it for J2EE and other specs. I believe that we're going to be in for
>> quite a bit of it because for all practical purposes, we'll be the
>> first use of the TCK on an independent implementation of Java SE.
>>
>> geir
>>
>>
>>>
>>> Thanks,
>>> Vladimir.
>>>
>>> On 4/24/06, Mikhail Loenko <ml...@gmail.com> wrote:
>>>> There is nothing about TCK here: if the spec requires to throw A
>>>> and we throw B that extends A then we follow the spec
>>>>
>>>> And if there is a TCK test that verifies that we throw A and only A
>>>> then the test is invalid and we will not have to pass it
>>>>
>>>> Sometimes it is an easy fix to throw A rather then B.
>>>>
>>>> But there could be two RI methods - one throwing A and another one
>>>> throwing B
>>>> such that in our implementation they both refer to some third method.
>>>>
>>>> In this case if we throw B in that 3rd method - then we conform the
>>>> spec,
>>>> we won't break existing apps and it might cause design weakening
>>>> if we choose to go coping how RI works.
>>>>
>>>> So if the fix is easy then I'd agree to what folks say here, but in
>>>> general case
>>>> I'd not set the rule to follow RI this way.
>>>>
>>>> Thanks,
>>>> Mikhail
>>>>
>>>> 2006/4/24, Vladimir Gorr <vv...@gmail.com>:
>>>>> The answer to this question (in my opinion) depends on how TCK
>>>>> processes
>>>>> similar situations.
>>>>> If we want to successfully perform this suite on Harmony we should be
>>>>> compatible with RI.
>>>>> For certain there are a lot of tests into TCK will fail due to this
>>>> reason
>>>>> and we should be ready for this.
>>>>>
>>>>> Thanks,
>>>>> Vladimir.
>>>>>
>>>>> On 4/24/06, Mikhail Loenko <ml...@gmail.com> wrote:
>>>>>> Look at HARMONY-387.
>>>>>>
>>>>>> Example:
>>>>>> 1) java.io.ByteArrayOutputStream.write(byte[] b , int off, int len):
>>>>>> Harmony throws ArrayIndexOutOfBoundsException when off<0 or/and len
>>>>>> <0, while RI throws IndexOutOfBoundsException.
>>>>>> Specification mentions neither ArrayIndexOutOfBoundsException nor
>>>>>> IndexOutOfBoundsException.
>>>>>>
>>>>>>
>>>>>> Actually ArrayIndexOutOfBoundsException is a sub class of
>>>>>> IndexOutOfBoundsException.
>>>>>>
>>>>>> So the statement "both Harmony and RI throw
>>>>>> IndexOutOfBoundsException"
>>>> is
>>>>>> true.
>>>>>>
>>>>>> But do we have to throw exactly those exceptions that are thrown by
>>>> RI?
>>>>>>
>>>>>> Can we throw
>>>>>> o.a.h.VMRisenNPE that extends NullPointerException?
>>>>>>
>>>>>> What if they throw kind of
>>>>>> sun.internal.SunFavoriteSubClassOfNullPointerException ?
>>>>>>
>>>>>> Thanks,
>>>>>> Mikhail
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>
>>
>
>
--
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: [classlib] matching RI exceptions -- are we required to have
this type of compatibility?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Jimmy, Jing Lv wrote:
> > Geir Magnusson Jr wrote:
>>
>>
>> Vladimir Gorr wrote:
>>> Mikhail,
>>>
>>> I also thought about this scenario. However, if any TCK tests will
>>> fail due
>>> to this reason
>>> we cannot certify our product. Nobody will talk about the invalidity
>>> of TCK.
>>> Most likely we will update our sources.
>>
>> 1) I hadn't thought about this before, but it seems much cleaner to
>> throw A (rather than B extends A) if the spec says to throw A.
>>
> I agree.
> But there are at least two exceptional situation:
> 1) several exceptions throws from one method, which extend one parent
> class, e.g. ConnectionException and UnknownHostException, javadoc writes
> "throws IOException" rather than "throws
> ConnectionException,UnknownHostException". And in implementation, we
> shall throw them out directly instead of
> try{...
> }catch(UnknownHostException e){
> throw new IOException();
> }
> catch(ConnectionException e){
> throw new IOException();
> }
> right? :)
Agreed. What I meant was not throwing some internal class whose
ancestor is ...
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: [classlib] matching RI exceptions -- are we required to have
this type of compatibility?
Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
> Geir Magnusson Jr wrote:
>
>
> Vladimir Gorr wrote:
>> Mikhail,
>>
>> I also thought about this scenario. However, if any TCK tests will
>> fail due
>> to this reason
>> we cannot certify our product. Nobody will talk about the invalidity
>> of TCK.
>> Most likely we will update our sources.
>
> 1) I hadn't thought about this before, but it seems much cleaner to
> throw A (rather than B extends A) if the spec says to throw A.
>
I agree.
But there are at least two exceptional situation:
1) several exceptions throws from one method, which extend one parent
class, e.g. ConnectionException and UnknownHostException, javadoc writes
"throws IOException" rather than "throws
ConnectionException,UnknownHostException". And in implementation, we
shall throw them out directly instead of
try{...
}catch(UnknownHostException e){
throw new IOException();
}
catch(ConnectionException e){
throw new IOException();
}
right? :)
2) and we may find some javadoc as "...then an unspecified error is
thrown." For an example, in java.util.jar.Pack200.newPacker(). We can do
nothing to meet such compatibility.
In summary, I think we shall follow doc in throwing exception; but if we
find it inconvenient indeed or even impossible, let it be. :)
> 2) You can challenge TCK tests and have them eliminated. We've done it
> for J2EE and other specs. I believe that we're going to be in for quite
> a bit of it because for all practical purposes, we'll be the first use
> of the TCK on an independent implementation of Java SE.
>
> geir
>
>
>>
>> Thanks,
>> Vladimir.
>>
>> On 4/24/06, Mikhail Loenko <ml...@gmail.com> wrote:
>>> There is nothing about TCK here: if the spec requires to throw A
>>> and we throw B that extends A then we follow the spec
>>>
>>> And if there is a TCK test that verifies that we throw A and only A
>>> then the test is invalid and we will not have to pass it
>>>
>>> Sometimes it is an easy fix to throw A rather then B.
>>>
>>> But there could be two RI methods - one throwing A and another one
>>> throwing B
>>> such that in our implementation they both refer to some third method.
>>>
>>> In this case if we throw B in that 3rd method - then we conform the
>>> spec,
>>> we won't break existing apps and it might cause design weakening
>>> if we choose to go coping how RI works.
>>>
>>> So if the fix is easy then I'd agree to what folks say here, but in
>>> general case
>>> I'd not set the rule to follow RI this way.
>>>
>>> Thanks,
>>> Mikhail
>>>
>>> 2006/4/24, Vladimir Gorr <vv...@gmail.com>:
>>>> The answer to this question (in my opinion) depends on how TCK
>>>> processes
>>>> similar situations.
>>>> If we want to successfully perform this suite on Harmony we should be
>>>> compatible with RI.
>>>> For certain there are a lot of tests into TCK will fail due to this
>>> reason
>>>> and we should be ready for this.
>>>>
>>>> Thanks,
>>>> Vladimir.
>>>>
>>>> On 4/24/06, Mikhail Loenko <ml...@gmail.com> wrote:
>>>>> Look at HARMONY-387.
>>>>>
>>>>> Example:
>>>>> 1) java.io.ByteArrayOutputStream.write(byte[] b , int off, int len):
>>>>> Harmony throws ArrayIndexOutOfBoundsException when off<0 or/and len
>>>>> <0, while RI throws IndexOutOfBoundsException.
>>>>> Specification mentions neither ArrayIndexOutOfBoundsException nor
>>>>> IndexOutOfBoundsException.
>>>>>
>>>>>
>>>>> Actually ArrayIndexOutOfBoundsException is a sub class of
>>>>> IndexOutOfBoundsException.
>>>>>
>>>>> So the statement "both Harmony and RI throw IndexOutOfBoundsException"
>>> is
>>>>> true.
>>>>>
>>>>> But do we have to throw exactly those exceptions that are thrown by
>>> RI?
>>>>>
>>>>> Can we throw
>>>>> o.a.h.VMRisenNPE that extends NullPointerException?
>>>>>
>>>>> What if they throw kind of
>>>>> sun.internal.SunFavoriteSubClassOfNullPointerException ?
>>>>>
>>>>> Thanks,
>>>>> Mikhail
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>
>
--
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: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
Posted by Mikhail Loenko <ml...@gmail.com>.
I'd back what Santiago said:
> I think the design should not suffer from such a problem, as
> the parent says. Only for trivial changes I'd rename an exception.
Thanks,.
Mikhail
2006/4/25, Geir Magnusson Jr <ge...@pobox.com>:
>
>
> Vladimir Gorr wrote:
> > Mikhail,
> >
> > I also thought about this scenario. However, if any TCK tests will fail due
> > to this reason
> > we cannot certify our product. Nobody will talk about the invalidity of TCK.
> > Most likely we will update our sources.
>
> 1) I hadn't thought about this before, but it seems much cleaner to
> throw A (rather than B extends A) if the spec says to throw A.
>
> 2) You can challenge TCK tests and have them eliminated. We've done it
> for J2EE and other specs. I believe that we're going to be in for quite
> a bit of it because for all practical purposes, we'll be the first use
> of the TCK on an independent implementation of Java SE.
>
> geir
>
>
> >
> > Thanks,
> > Vladimir.
> >
> > On 4/24/06, Mikhail Loenko <ml...@gmail.com> wrote:
> >> There is nothing about TCK here: if the spec requires to throw A
> >> and we throw B that extends A then we follow the spec
> >>
> >> And if there is a TCK test that verifies that we throw A and only A
> >> then the test is invalid and we will not have to pass it
> >>
> >> Sometimes it is an easy fix to throw A rather then B.
> >>
> >> But there could be two RI methods - one throwing A and another one
> >> throwing B
> >> such that in our implementation they both refer to some third method.
> >>
> >> In this case if we throw B in that 3rd method - then we conform the spec,
> >> we won't break existing apps and it might cause design weakening
> >> if we choose to go coping how RI works.
> >>
> >> So if the fix is easy then I'd agree to what folks say here, but in
> >> general case
> >> I'd not set the rule to follow RI this way.
> >>
> >> Thanks,
> >> Mikhail
> >>
> >> 2006/4/24, Vladimir Gorr <vv...@gmail.com>:
> >>> The answer to this question (in my opinion) depends on how TCK processes
> >>> similar situations.
> >>> If we want to successfully perform this suite on Harmony we should be
> >>> compatible with RI.
> >>> For certain there are a lot of tests into TCK will fail due to this
> >> reason
> >>> and we should be ready for this.
> >>>
> >>> Thanks,
> >>> Vladimir.
> >>>
> >>> On 4/24/06, Mikhail Loenko <ml...@gmail.com> wrote:
> >>>> Look at HARMONY-387.
> >>>>
> >>>> Example:
> >>>> 1) java.io.ByteArrayOutputStream.write(byte[] b , int off, int len):
> >>>> Harmony throws ArrayIndexOutOfBoundsException when off<0 or/and len
> >>>> <0, while RI throws IndexOutOfBoundsException.
> >>>> Specification mentions neither ArrayIndexOutOfBoundsException nor
> >>>> IndexOutOfBoundsException.
> >>>>
> >>>>
> >>>> Actually ArrayIndexOutOfBoundsException is a sub class of
> >>>> IndexOutOfBoundsException.
> >>>>
> >>>> So the statement "both Harmony and RI throw IndexOutOfBoundsException"
> >> is
> >>>> true.
> >>>>
> >>>> But do we have to throw exactly those exceptions that are thrown by
> >> RI?
> >>>>
> >>>> Can we throw
> >>>> o.a.h.VMRisenNPE that extends NullPointerException?
> >>>>
> >>>> What if they throw kind of
> >>>> sun.internal.SunFavoriteSubClassOfNullPointerException ?
> >>>>
> >>>> Thanks,
> >>>> Mikhail
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> 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: [classlib] matching RI exceptions -- are we required to have
this type of compatibility?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Vladimir Gorr wrote:
> Mikhail,
>
> I also thought about this scenario. However, if any TCK tests will fail due
> to this reason
> we cannot certify our product. Nobody will talk about the invalidity of TCK.
> Most likely we will update our sources.
1) I hadn't thought about this before, but it seems much cleaner to
throw A (rather than B extends A) if the spec says to throw A.
2) You can challenge TCK tests and have them eliminated. We've done it
for J2EE and other specs. I believe that we're going to be in for quite
a bit of it because for all practical purposes, we'll be the first use
of the TCK on an independent implementation of Java SE.
geir
>
> Thanks,
> Vladimir.
>
> On 4/24/06, Mikhail Loenko <ml...@gmail.com> wrote:
>> There is nothing about TCK here: if the spec requires to throw A
>> and we throw B that extends A then we follow the spec
>>
>> And if there is a TCK test that verifies that we throw A and only A
>> then the test is invalid and we will not have to pass it
>>
>> Sometimes it is an easy fix to throw A rather then B.
>>
>> But there could be two RI methods - one throwing A and another one
>> throwing B
>> such that in our implementation they both refer to some third method.
>>
>> In this case if we throw B in that 3rd method - then we conform the spec,
>> we won't break existing apps and it might cause design weakening
>> if we choose to go coping how RI works.
>>
>> So if the fix is easy then I'd agree to what folks say here, but in
>> general case
>> I'd not set the rule to follow RI this way.
>>
>> Thanks,
>> Mikhail
>>
>> 2006/4/24, Vladimir Gorr <vv...@gmail.com>:
>>> The answer to this question (in my opinion) depends on how TCK processes
>>> similar situations.
>>> If we want to successfully perform this suite on Harmony we should be
>>> compatible with RI.
>>> For certain there are a lot of tests into TCK will fail due to this
>> reason
>>> and we should be ready for this.
>>>
>>> Thanks,
>>> Vladimir.
>>>
>>> On 4/24/06, Mikhail Loenko <ml...@gmail.com> wrote:
>>>> Look at HARMONY-387.
>>>>
>>>> Example:
>>>> 1) java.io.ByteArrayOutputStream.write(byte[] b , int off, int len):
>>>> Harmony throws ArrayIndexOutOfBoundsException when off<0 or/and len
>>>> <0, while RI throws IndexOutOfBoundsException.
>>>> Specification mentions neither ArrayIndexOutOfBoundsException nor
>>>> IndexOutOfBoundsException.
>>>>
>>>>
>>>> Actually ArrayIndexOutOfBoundsException is a sub class of
>>>> IndexOutOfBoundsException.
>>>>
>>>> So the statement "both Harmony and RI throw IndexOutOfBoundsException"
>> is
>>>> true.
>>>>
>>>> But do we have to throw exactly those exceptions that are thrown by
>> RI?
>>>>
>>>> Can we throw
>>>> o.a.h.VMRisenNPE that extends NullPointerException?
>>>>
>>>> What if they throw kind of
>>>> sun.internal.SunFavoriteSubClassOfNullPointerException ?
>>>>
>>>> Thanks,
>>>> Mikhail
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
Posted by Vladimir Gorr <vv...@gmail.com>.
On 4/24/06, Santiago Gala <sg...@apache.org> wrote:
>
> El lun, 24-04-2006 a las 14:48 +0700, Vladimir Gorr escribió:
> > Mikhail,
> >
> > I also thought about this scenario. However, if any TCK tests will fail
> due
> > to this reason we cannot certify our product. Nobody will talk about the
> invalidity of TCK.
> > Most likely we will update our sources.
> >
>
> Not really. The TCK processes have provisions for such "TCK bug
> reports". I think the design should not suffer from such a problem, as
> the parent says. Only for trivial changes I'd rename an exception. Or
> temporarily, while the TCK gets amended.
Ok, I see. It's fine there is such possibility to correct the TCK suite.
Thanks,
Vladimir.
Regards
> Santiago
>
> > Thanks,
> > Vladimir.
> >
> > On 4/24/06, Mikhail Loenko <ml...@gmail.com> wrote:
> > >
> > > There is nothing about TCK here: if the spec requires to throw A
> > > and we throw B that extends A then we follow the spec
> > >
> > > And if there is a TCK test that verifies that we throw A and only A
> > > then the test is invalid and we will not have to pass it
> > >
> > > Sometimes it is an easy fix to throw A rather then B.
> > >
> > > But there could be two RI methods - one throwing A and another one
> > > throwing B
> > > such that in our implementation they both refer to some third method.
> > >
> > > In this case if we throw B in that 3rd method - then we conform the
> spec,
> > > we won't break existing apps and it might cause design weakening
> > > if we choose to go coping how RI works.
> > >
> > > So if the fix is easy then I'd agree to what folks say here, but in
> > > general case
> > > I'd not set the rule to follow RI this way.
> > >
> > > Thanks,
> > > Mikhail
> > >
> > > 2006/4/24, Vladimir Gorr <vv...@gmail.com>:
> > > > The answer to this question (in my opinion) depends on how TCK
> processes
> > > > similar situations.
> > > > If we want to successfully perform this suite on Harmony we should
> be
> > > > compatible with RI.
> > > > For certain there are a lot of tests into TCK will fail due to this
> > > reason
> > > > and we should be ready for this.
> > > >
> > > > Thanks,
> > > > Vladimir.
> > > >
> > > > On 4/24/06, Mikhail Loenko <ml...@gmail.com> wrote:
> > > > >
> > > > > Look at HARMONY-387.
> > > > >
> > > > > Example:
> > > > > 1) java.io.ByteArrayOutputStream.write(byte[] b , int off, int
> len):
> > > > > Harmony throws ArrayIndexOutOfBoundsException when off<0 or/and
> len
> > > > > <0, while RI throws IndexOutOfBoundsException.
> > > > > Specification mentions neither ArrayIndexOutOfBoundsException nor
> > > > > IndexOutOfBoundsException.
> > > > >
> > > > >
> > > > > Actually ArrayIndexOutOfBoundsException is a sub class of
> > > > > IndexOutOfBoundsException.
> > > > >
> > > > > So the statement "both Harmony and RI throw
> IndexOutOfBoundsException"
> > > is
> > > > > true.
> > > > >
> > > > > But do we have to throw exactly those exceptions that are thrown
> by
> > > RI?
> > > > >
> > > > >
> > > > > Can we throw
> > > > > o.a.h.VMRisenNPE that extends NullPointerException?
> > > > >
> > > > > What if they throw kind of
> > > > > sun.internal.SunFavoriteSubClassOfNullPointerException ?
> > > > >
> > > > > Thanks,
> > > > > Mikhail
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > 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
> > >
> > >
> --
> VP and Chair, Apache Portals (http://portals.apache.org)
> Apache Software Foundation
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
>
> iD8DBQBETKxdZAeG2a2/nhoRAnOPAKCBJ2B0Tqtw8XW/bIw786dFrOkdIwCeKZv/
> Tm864my+0rgxf484HkKifWI=
> =3z/i
> -----END PGP SIGNATURE-----
>
>
>
Re: [classlib] matching RI exceptions -- are we required to have
this type of compatibility?
Posted by Santiago Gala <sg...@apache.org>.
El lun, 24-04-2006 a las 14:48 +0700, Vladimir Gorr escribió:
> Mikhail,
>
> I also thought about this scenario. However, if any TCK tests will fail due
> to this reason we cannot certify our product. Nobody will talk about the invalidity of TCK.
> Most likely we will update our sources.
>
Not really. The TCK processes have provisions for such "TCK bug
reports". I think the design should not suffer from such a problem, as
the parent says. Only for trivial changes I'd rename an exception. Or
temporarily, while the TCK gets amended.
Regards
Santiago
> Thanks,
> Vladimir.
>
> On 4/24/06, Mikhail Loenko <ml...@gmail.com> wrote:
> >
> > There is nothing about TCK here: if the spec requires to throw A
> > and we throw B that extends A then we follow the spec
> >
> > And if there is a TCK test that verifies that we throw A and only A
> > then the test is invalid and we will not have to pass it
> >
> > Sometimes it is an easy fix to throw A rather then B.
> >
> > But there could be two RI methods - one throwing A and another one
> > throwing B
> > such that in our implementation they both refer to some third method.
> >
> > In this case if we throw B in that 3rd method - then we conform the spec,
> > we won't break existing apps and it might cause design weakening
> > if we choose to go coping how RI works.
> >
> > So if the fix is easy then I'd agree to what folks say here, but in
> > general case
> > I'd not set the rule to follow RI this way.
> >
> > Thanks,
> > Mikhail
> >
> > 2006/4/24, Vladimir Gorr <vv...@gmail.com>:
> > > The answer to this question (in my opinion) depends on how TCK processes
> > > similar situations.
> > > If we want to successfully perform this suite on Harmony we should be
> > > compatible with RI.
> > > For certain there are a lot of tests into TCK will fail due to this
> > reason
> > > and we should be ready for this.
> > >
> > > Thanks,
> > > Vladimir.
> > >
> > > On 4/24/06, Mikhail Loenko <ml...@gmail.com> wrote:
> > > >
> > > > Look at HARMONY-387.
> > > >
> > > > Example:
> > > > 1) java.io.ByteArrayOutputStream.write(byte[] b , int off, int len):
> > > > Harmony throws ArrayIndexOutOfBoundsException when off<0 or/and len
> > > > <0, while RI throws IndexOutOfBoundsException.
> > > > Specification mentions neither ArrayIndexOutOfBoundsException nor
> > > > IndexOutOfBoundsException.
> > > >
> > > >
> > > > Actually ArrayIndexOutOfBoundsException is a sub class of
> > > > IndexOutOfBoundsException.
> > > >
> > > > So the statement "both Harmony and RI throw IndexOutOfBoundsException"
> > is
> > > > true.
> > > >
> > > > But do we have to throw exactly those exceptions that are thrown by
> > RI?
> > > >
> > > >
> > > > Can we throw
> > > > o.a.h.VMRisenNPE that extends NullPointerException?
> > > >
> > > > What if they throw kind of
> > > > sun.internal.SunFavoriteSubClassOfNullPointerException ?
> > > >
> > > > Thanks,
> > > > Mikhail
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
> >
> >
--
VP and Chair, Apache Portals (http://portals.apache.org)
Apache Software Foundation
Re: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
Posted by Vladimir Gorr <vv...@gmail.com>.
Mikhail,
I also thought about this scenario. However, if any TCK tests will fail due
to this reason
we cannot certify our product. Nobody will talk about the invalidity of TCK.
Most likely we will update our sources.
Thanks,
Vladimir.
On 4/24/06, Mikhail Loenko <ml...@gmail.com> wrote:
>
> There is nothing about TCK here: if the spec requires to throw A
> and we throw B that extends A then we follow the spec
>
> And if there is a TCK test that verifies that we throw A and only A
> then the test is invalid and we will not have to pass it
>
> Sometimes it is an easy fix to throw A rather then B.
>
> But there could be two RI methods - one throwing A and another one
> throwing B
> such that in our implementation they both refer to some third method.
>
> In this case if we throw B in that 3rd method - then we conform the spec,
> we won't break existing apps and it might cause design weakening
> if we choose to go coping how RI works.
>
> So if the fix is easy then I'd agree to what folks say here, but in
> general case
> I'd not set the rule to follow RI this way.
>
> Thanks,
> Mikhail
>
> 2006/4/24, Vladimir Gorr <vv...@gmail.com>:
> > The answer to this question (in my opinion) depends on how TCK processes
> > similar situations.
> > If we want to successfully perform this suite on Harmony we should be
> > compatible with RI.
> > For certain there are a lot of tests into TCK will fail due to this
> reason
> > and we should be ready for this.
> >
> > Thanks,
> > Vladimir.
> >
> > On 4/24/06, Mikhail Loenko <ml...@gmail.com> wrote:
> > >
> > > Look at HARMONY-387.
> > >
> > > Example:
> > > 1) java.io.ByteArrayOutputStream.write(byte[] b , int off, int len):
> > > Harmony throws ArrayIndexOutOfBoundsException when off<0 or/and len
> > > <0, while RI throws IndexOutOfBoundsException.
> > > Specification mentions neither ArrayIndexOutOfBoundsException nor
> > > IndexOutOfBoundsException.
> > >
> > >
> > > Actually ArrayIndexOutOfBoundsException is a sub class of
> > > IndexOutOfBoundsException.
> > >
> > > So the statement "both Harmony and RI throw IndexOutOfBoundsException"
> is
> > > true.
> > >
> > > But do we have to throw exactly those exceptions that are thrown by
> RI?
> > >
> > >
> > > Can we throw
> > > o.a.h.VMRisenNPE that extends NullPointerException?
> > >
> > > What if they throw kind of
> > > sun.internal.SunFavoriteSubClassOfNullPointerException ?
> > >
> > > Thanks,
> > > Mikhail
> > >
> > > ---------------------------------------------------------------------
> > > 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: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
Posted by Mikhail Loenko <ml...@gmail.com>.
There is nothing about TCK here: if the spec requires to throw A
and we throw B that extends A then we follow the spec
And if there is a TCK test that verifies that we throw A and only A
then the test is invalid and we will not have to pass it
Sometimes it is an easy fix to throw A rather then B.
But there could be two RI methods - one throwing A and another one throwing B
such that in our implementation they both refer to some third method.
In this case if we throw B in that 3rd method - then we conform the spec,
we won't break existing apps and it might cause design weakening
if we choose to go coping how RI works.
So if the fix is easy then I'd agree to what folks say here, but in general case
I'd not set the rule to follow RI this way.
Thanks,
Mikhail
2006/4/24, Vladimir Gorr <vv...@gmail.com>:
> The answer to this question (in my opinion) depends on how TCK processes
> similar situations.
> If we want to successfully perform this suite on Harmony we should be
> compatible with RI.
> For certain there are a lot of tests into TCK will fail due to this reason
> and we should be ready for this.
>
> Thanks,
> Vladimir.
>
> On 4/24/06, Mikhail Loenko <ml...@gmail.com> wrote:
> >
> > Look at HARMONY-387.
> >
> > Example:
> > 1) java.io.ByteArrayOutputStream.write(byte[] b , int off, int len):
> > Harmony throws ArrayIndexOutOfBoundsException when off<0 or/and len
> > <0, while RI throws IndexOutOfBoundsException.
> > Specification mentions neither ArrayIndexOutOfBoundsException nor
> > IndexOutOfBoundsException.
> >
> >
> > Actually ArrayIndexOutOfBoundsException is a sub class of
> > IndexOutOfBoundsException.
> >
> > So the statement "both Harmony and RI throw IndexOutOfBoundsException" is
> > true.
> >
> > But do we have to throw exactly those exceptions that are thrown by RI?
> >
> >
> > Can we throw
> > o.a.h.VMRisenNPE that extends NullPointerException?
> >
> > What if they throw kind of
> > sun.internal.SunFavoriteSubClassOfNullPointerException ?
> >
> > Thanks,
> > Mikhail
> >
> > ---------------------------------------------------------------------
> > 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: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
Posted by Vladimir Gorr <vv...@gmail.com>.
The answer to this question (in my opinion) depends on how TCK processes
similar situations.
If we want to successfully perform this suite on Harmony we should be
compatible with RI.
For certain there are a lot of tests into TCK will fail due to this reason
and we should be ready for this.
Thanks,
Vladimir.
On 4/24/06, Mikhail Loenko <ml...@gmail.com> wrote:
>
> Look at HARMONY-387.
>
> Example:
> 1) java.io.ByteArrayOutputStream.write(byte[] b , int off, int len):
> Harmony throws ArrayIndexOutOfBoundsException when off<0 or/and len
> <0, while RI throws IndexOutOfBoundsException.
> Specification mentions neither ArrayIndexOutOfBoundsException nor
> IndexOutOfBoundsException.
>
>
> Actually ArrayIndexOutOfBoundsException is a sub class of
> IndexOutOfBoundsException.
>
> So the statement "both Harmony and RI throw IndexOutOfBoundsException" is
> true.
>
> But do we have to throw exactly those exceptions that are thrown by RI?
>
>
> Can we throw
> o.a.h.VMRisenNPE that extends NullPointerException?
>
> What if they throw kind of
> sun.internal.SunFavoriteSubClassOfNullPointerException ?
>
> Thanks,
> Mikhail
>
> ---------------------------------------------------------------------
> 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: [classlib] matching RI exceptions -- are we required to have
this type of compatibility?
Posted by Andrew Zhang <zh...@gmail.com>.
Anton Avtamonov wrote:
> On 4/24/06, Mikhail Loenko <ml...@gmail.com> wrote:
>> Look at HARMONY-387.
>>
>> Example:
>> 1) java.io.ByteArrayOutputStream.write(byte[] b , int off, int len):
>> Harmony throws ArrayIndexOutOfBoundsException when off<0 or/and len
>> <0, while RI throws IndexOutOfBoundsException.
>> Specification mentions neither ArrayIndexOutOfBoundsException nor
>> IndexOutOfBoundsException.
>>
>>
>> Actually ArrayIndexOutOfBoundsException is a sub class of
>> IndexOutOfBoundsException.
>>
>> So the statement "both Harmony and RI throw IndexOutOfBoundsException" is
>> true.
>>
>> But do we have to throw exactly those exceptions that are thrown by RI?
Yes. Harmony should throw the exactly same exception in this case.
>
> I think so. If RI behavior is reasonable and doesn't contradict to the
> spec (as above) we should unconditionally copy RI behavior.
>
+1.
Only When RI doesn't behave as spec or it's impossible for Harmony to
throw the exact exception as RI(I don't know whether RI throws
com.sun.internal.SunNullPointerException in some cases), we should
discuss whether to follow RI or follow spec or behave as Harmony style :)
> Really, why do we need additional differences even though we
> absolutely sure that particular minor deviation would have no impact
> on client apps?
>
>
>> Can we throw
>> o.a.h.VMRisenNPE that extends NullPointerException?
>>
>> What if they throw kind of
>> sun.internal.SunFavoriteSubClassOfNullPointerException ?
>
> Yeah, in case RI operates with classes not from public API I would
> propose to base on spec. Or use the nearest class from public API if
> spec doesn't work for some reasons.
> Actually, spec even contains sometimes references to the classes from
> not public API...
>
> Wishes,
> --
> 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
>
>
---------------------------------------------------------------------
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: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
Posted by Anton Avtamonov <an...@gmail.com>.
On 4/24/06, Mikhail Loenko <ml...@gmail.com> wrote:
<SNIP>
> > Yeah, in case RI operates with classes not from public API I would
> > propose to base on spec. Or use the nearest class from public API if
> > spec doesn't work for some reasons.
> > Actually, spec even contains sometimes references to the classes from
> > not public API...
>
> Really? You mean that the spec is not transitively close?
> Can you give an example?
Of course. I saw that many times. Just the first I can recall:
MetalScrollBarUI.bumps
Field bumps is of type which is not public api: the reference is not
hyperlinked.
If you want I can find some other cases: I definitely saw more than one :-)
Wishes
--
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: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
Posted by Mikhail Loenko <ml...@gmail.com>.
2006/4/24, Anton Avtamonov <an...@gmail.com>:
> On 4/24/06, Mikhail Loenko <ml...@gmail.com> wrote:
> > Look at HARMONY-387.
> >
> > Example:
> > 1) java.io.ByteArrayOutputStream.write(byte[] b , int off, int len):
> > Harmony throws ArrayIndexOutOfBoundsException when off<0 or/and len
> > <0, while RI throws IndexOutOfBoundsException.
> > Specification mentions neither ArrayIndexOutOfBoundsException nor
> > IndexOutOfBoundsException.
> >
> >
> > Actually ArrayIndexOutOfBoundsException is a sub class of
> > IndexOutOfBoundsException.
> >
> > So the statement "both Harmony and RI throw IndexOutOfBoundsException" is
> > true.
> >
> > But do we have to throw exactly those exceptions that are thrown by RI?
>
> I think so. If RI behavior is reasonable and doesn't contradict to the
> spec (as above) we should unconditionally copy RI behavior.
>
> Really, why do we need additional differences even though we
> absolutely sure that particular minor deviation would have no impact
> on client apps?
>
>
> > Can we throw
> > o.a.h.VMRisenNPE that extends NullPointerException?
> >
> > What if they throw kind of
> > sun.internal.SunFavoriteSubClassOfNullPointerException ?
>
> Yeah, in case RI operates with classes not from public API I would
> propose to base on spec. Or use the nearest class from public API if
> spec doesn't work for some reasons.
> Actually, spec even contains sometimes references to the classes from
> not public API...
Really? You mean that the spec is not transitively close?
Can you give an example?
Thanks,
Mikhail
>
> Wishes,
> --
> 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
>
>
---------------------------------------------------------------------
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: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
Posted by Anton Avtamonov <an...@gmail.com>.
On 4/24/06, Mikhail Loenko <ml...@gmail.com> wrote:
> Look at HARMONY-387.
>
> Example:
> 1) java.io.ByteArrayOutputStream.write(byte[] b , int off, int len):
> Harmony throws ArrayIndexOutOfBoundsException when off<0 or/and len
> <0, while RI throws IndexOutOfBoundsException.
> Specification mentions neither ArrayIndexOutOfBoundsException nor
> IndexOutOfBoundsException.
>
>
> Actually ArrayIndexOutOfBoundsException is a sub class of
> IndexOutOfBoundsException.
>
> So the statement "both Harmony and RI throw IndexOutOfBoundsException" is
> true.
>
> But do we have to throw exactly those exceptions that are thrown by RI?
I think so. If RI behavior is reasonable and doesn't contradict to the
spec (as above) we should unconditionally copy RI behavior.
Really, why do we need additional differences even though we
absolutely sure that particular minor deviation would have no impact
on client apps?
> Can we throw
> o.a.h.VMRisenNPE that extends NullPointerException?
>
> What if they throw kind of
> sun.internal.SunFavoriteSubClassOfNullPointerException ?
Yeah, in case RI operates with classes not from public API I would
propose to base on spec. Or use the nearest class from public API if
spec doesn't work for some reasons.
Actually, spec even contains sometimes references to the classes from
not public API...
Wishes,
--
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