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/06/30 09:48:37 UTC
[classlib] Exception-throwing compatibility question
Do I undersyand correctly that even when spec says e.g.
that Exception1 is thrown when parameter1 == 10 and RI
throws Exception2 then we follow RI ?
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] Exception-throwing compatibility question
Posted by Andrew Zhang <zh...@gmail.com>.
George,
Totally agree with you.
Shall we summarize and document the discuss to Harmony exception-thrown
compatibility guideline?
Thanks!
On 6/30/06, George Harley <ge...@googlemail.com> wrote:
>
> Mikhail Loenko wrote:
> > For the example I've started this thread with it seems that complying
> > the spec is
> > more appropriate there. But probably there are other examples that
> > caused that the doc was worded the given way
> >
> > George and Tim could you please comment?
> >
> > Thanks,
> > Mikhail
>
> Hi Mikhail,
>
> I love this topic !
>
> FWIW, my gut feel is that we should minimise any disruption to user
> applications that move from RI to Harmony. If the spec says Exception1
> should result and the RI actually throws Exception2 then my preference
> would be for the Harmony code to throw Exception2 (i.e. match the
> runtime behaviour of the RI) and raise the matter in a Sun bug. There is
> always the possibility that it is the method Javadoc that is incorrect.
> If and when the matter gets addressed in the RI so that the spec and the
> behaviour coincide, we make any necessary updates to our code. That way
> we help clarify the spec and keep ourselves consistent with what
> migrating users expect from their Java runtime.
>
> Sure, it is a problem if user application code critically depends on the
> kind of exception thrown from an API call but I would sooner have people
> using Harmony to run their apps with zero/minimal changes required than
> see breakages because Harmony has taken the moral high ground on a spec
> issue.
>
> OK, you can all start throwing rocks at me now :-)
>
> Best regards,
> George
>
>
> >
> >
> > 2006/6/30, Paulex Yang <pa...@gmail.com>:
> >> Anton Avtamonov wrote:
> >> > On 6/30/06, Mikhail Loenko <ml...@gmail.com> wrote:
> >> >> But section "Exception-throwing compatibility" says that exceptions
> >> >> are different
> >> >> and we aim "to be fully compartible with the RI" "by matching the
> >> >> exception characteristics of each method".
> >> >
> >> > I believe that it is for "However, in most cases the specification
> >> > does not describe all possible exceptions that may be thrown" case
> >> > only.
> >> > In case the spec is complete and not looks like a bug I would vote to
> >> > follow the spec.
> >> +1 from me.
> >> >
> >> > Wishes,
> >>
> >>
> >> --
> >> 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
> >
> >
>
>
> ---------------------------------------------------------------------
> 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
>
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: [classlib] Exception-throwing compatibility question
Posted by Richard Liang <ri...@gmail.com>.
Hello George,
Agree. We shall always following RI when throwing exception. But Harmony
"developer" could discuss specific problems on mailing list if he/she
feels uncomfortable. ;-)
George Harley wrote:
> Mikhail Loenko wrote:
>> For the example I've started this thread with it seems that complying
>> the spec is
>> more appropriate there. But probably there are other examples that
>> caused that the doc was worded the given way
>>
>> George and Tim could you please comment?
>>
>> Thanks,
>> Mikhail
>
> Hi Mikhail,
>
> I love this topic !
>
> FWIW, my gut feel is that we should minimise any disruption to user
> applications that move from RI to Harmony. If the spec says Exception1
> should result and the RI actually throws Exception2 then my preference
> would be for the Harmony code to throw Exception2 (i.e. match the
> runtime behaviour of the RI) and raise the matter in a Sun bug. There
> is always the possibility that it is the method Javadoc that is
> incorrect. If and when the matter gets addressed in the RI so that the
> spec and the behaviour coincide, we make any necessary updates to our
> code. That way we help clarify the spec and keep ourselves consistent
> with what migrating users expect from their Java runtime.
>
> Sure, it is a problem if user application code critically depends on
> the kind of exception thrown from an API call but I would sooner have
> people using Harmony to run their apps with zero/minimal changes
> required than see breakages because Harmony has taken the moral high
> ground on a spec issue.
>
> OK, you can all start throwing rocks at me now :-)
>
> Best regards,
> George
>
>
>>
>>
>> 2006/6/30, Paulex Yang <pa...@gmail.com>:
>>> Anton Avtamonov wrote:
>>> > On 6/30/06, Mikhail Loenko <ml...@gmail.com> wrote:
>>> >> But section "Exception-throwing compatibility" says that exceptions
>>> >> are different
>>> >> and we aim "to be fully compartible with the RI" "by matching the
>>> >> exception characteristics of each method".
>>> >
>>> > I believe that it is for "However, in most cases the specification
>>> > does not describe all possible exceptions that may be thrown" case
>>> > only.
>>> > In case the spec is complete and not looks like a bug I would vote to
>>> > follow the spec.
>>> +1 from me.
>>> >
>>> > Wishes,
>>>
>>>
>>> --
>>> 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
>>
>>
>
>
> ---------------------------------------------------------------------
> 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
>
>
--
Richard Liang
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] Exception-throwing compatibility question
Posted by George Harley <ge...@googlemail.com>.
Mikhail Loenko wrote:
> For the example I've started this thread with it seems that complying
> the spec is
> more appropriate there. But probably there are other examples that
> caused that the doc was worded the given way
>
> George and Tim could you please comment?
>
> Thanks,
> Mikhail
Hi Mikhail,
I love this topic !
FWIW, my gut feel is that we should minimise any disruption to user
applications that move from RI to Harmony. If the spec says Exception1
should result and the RI actually throws Exception2 then my preference
would be for the Harmony code to throw Exception2 (i.e. match the
runtime behaviour of the RI) and raise the matter in a Sun bug. There is
always the possibility that it is the method Javadoc that is incorrect.
If and when the matter gets addressed in the RI so that the spec and the
behaviour coincide, we make any necessary updates to our code. That way
we help clarify the spec and keep ourselves consistent with what
migrating users expect from their Java runtime.
Sure, it is a problem if user application code critically depends on the
kind of exception thrown from an API call but I would sooner have people
using Harmony to run their apps with zero/minimal changes required than
see breakages because Harmony has taken the moral high ground on a spec
issue.
OK, you can all start throwing rocks at me now :-)
Best regards,
George
>
>
> 2006/6/30, Paulex Yang <pa...@gmail.com>:
>> Anton Avtamonov wrote:
>> > On 6/30/06, Mikhail Loenko <ml...@gmail.com> wrote:
>> >> But section "Exception-throwing compatibility" says that exceptions
>> >> are different
>> >> and we aim "to be fully compartible with the RI" "by matching the
>> >> exception characteristics of each method".
>> >
>> > I believe that it is for "However, in most cases the specification
>> > does not describe all possible exceptions that may be thrown" case
>> > only.
>> > In case the spec is complete and not looks like a bug I would vote to
>> > follow the spec.
>> +1 from me.
>> >
>> > Wishes,
>>
>>
>> --
>> 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
>
>
---------------------------------------------------------------------
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] Exception-throwing compatibility question
Posted by Chris Gray <ch...@kiffer.be>.
On Monday 03 July 2006 14:33, Andrew Zhang wrote:
> Maybe it's called "javadoc bug or spec bug". :)
Looks to me very like "oops, our implementation isn't according to spec,
better change the spec". To be fair to Sun, fixing the implementation could
have broken existing code (maybe it did, hence the decision to "fix" the spec
instead).
Chris
---------------------------------------------------------------------
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] Exception-throwing compatibility question
Posted by Andrew Zhang <zh...@gmail.com>.
Maybe it's called "javadoc bug or spec bug". :)
On 7/3/06, Chris Gray <ch...@kiffer.be> wrote:
>
> In 1.4.2 it was a bug, but in 1.5.0 it's a feature. :-) What a difference
> a
> doc makes ...
>
> Chris
>
> On Monday 03 July 2006 14:12, Anton Luht wrote:
> > Hello,
> >
> > There's one example that shows that not only code may contain bugs,
> > but documentation also:
> >
> > 1.5.0 spec [1] says about java.io.BufferedWriter.write(String, int, int)
> >
> > If the value of the len parameter is negative then no characters are
> > written. This is contrary to the specification of this method in the
> > superclass, which requires that an IndexOutOfBoundsException be
> > thrown.
> >
> > 1.4.2 spec [2] doesn't say this, but 1.4.2 JRE behaves as it was
> > written according to 1.5 doc. If it is not said, we expect that
> > BufferedWriter should behave like Writer in this case (throw an
> > exception) so this behaviour is formally a bug. In fact this is just a
> > gap in documentation.
> >
> > [1]
> >
> http://java.sun.com/j2se/1.5.0/docs/api/java/io/BufferedWriter.html#write(j
> >ava.lang.String,%20int,%20int) [2]
> >
> http://java.sun.com/j2se/1.4.2/docs/api/java/io/BufferedWriter.html#write(j
> >ava.lang.String,%20int,%20int)
> >
> > On 7/3/06, Tim Ellison <t....@gmail.com> wrote:
> > > Mikhail Loenko wrote:
> > > > For the example I've started this thread with it seems that
> complying
> > > > the spec is
> > > > more appropriate there. But probably there are other examples that
> > > > caused that the doc was worded the given way
> > > >
> > > > George and Tim could you please comment?
> > >
> > > What is the concrete example? e.g. are these checked exceptions, ...
> ?
> > > or NPE vs. IAE ...
> > >
> > > Regards,
> > > Tim
> > >
> > > > 2006/6/30, Paulex Yang <pa...@gmail.com>:
> > > >> Anton Avtamonov wrote:
> > > >> > On 6/30/06, Mikhail Loenko <ml...@gmail.com> wrote:
> > > >> >> But section "Exception-throwing compatibility" says that
> exceptions
> > > >> >> are different
> > > >> >> and we aim "to be fully compartible with the RI" "by matching
> the
> > > >> >> exception characteristics of each method".
> > > >> >
> > > >> > I believe that it is for "However, in most cases the
> specification
> > > >> > does not describe all possible exceptions that may be thrown"
> case
> > > >> > only.
> > > >> > In case the spec is complete and not looks like a bug I would
> vote
> > > >> > to follow the spec.
> > > >>
> > > >> +1 from me.
> > > >>
> > > >> > Wishes,
> > > >>
> > > >> --
> > > >> 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
> > >
> > > --
> > >
> > > 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
>
> --
> Chris Gray /k/ Embedded Java Solutions BE0503765045
> Embedded & Mobile Java, OSGi http://www.k-embedded-java.com/
> chris.gray@kiffer.be +32 3 216 0369
>
>
> ---------------------------------------------------------------------
> 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
>
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: [classlib] Exception-throwing compatibility question
Posted by Chris Gray <ch...@kiffer.be>.
In 1.4.2 it was a bug, but in 1.5.0 it's a feature. :-) What a difference a
doc makes ...
Chris
On Monday 03 July 2006 14:12, Anton Luht wrote:
> Hello,
>
> There's one example that shows that not only code may contain bugs,
> but documentation also:
>
> 1.5.0 spec [1] says about java.io.BufferedWriter.write(String, int, int)
>
> If the value of the len parameter is negative then no characters are
> written. This is contrary to the specification of this method in the
> superclass, which requires that an IndexOutOfBoundsException be
> thrown.
>
> 1.4.2 spec [2] doesn't say this, but 1.4.2 JRE behaves as it was
> written according to 1.5 doc. If it is not said, we expect that
> BufferedWriter should behave like Writer in this case (throw an
> exception) so this behaviour is formally a bug. In fact this is just a
> gap in documentation.
>
> [1]
> http://java.sun.com/j2se/1.5.0/docs/api/java/io/BufferedWriter.html#write(j
>ava.lang.String,%20int,%20int) [2]
> http://java.sun.com/j2se/1.4.2/docs/api/java/io/BufferedWriter.html#write(j
>ava.lang.String,%20int,%20int)
>
> On 7/3/06, Tim Ellison <t....@gmail.com> wrote:
> > Mikhail Loenko wrote:
> > > For the example I've started this thread with it seems that complying
> > > the spec is
> > > more appropriate there. But probably there are other examples that
> > > caused that the doc was worded the given way
> > >
> > > George and Tim could you please comment?
> >
> > What is the concrete example? e.g. are these checked exceptions, ... ?
> > or NPE vs. IAE ...
> >
> > Regards,
> > Tim
> >
> > > 2006/6/30, Paulex Yang <pa...@gmail.com>:
> > >> Anton Avtamonov wrote:
> > >> > On 6/30/06, Mikhail Loenko <ml...@gmail.com> wrote:
> > >> >> But section "Exception-throwing compatibility" says that exceptions
> > >> >> are different
> > >> >> and we aim "to be fully compartible with the RI" "by matching the
> > >> >> exception characteristics of each method".
> > >> >
> > >> > I believe that it is for "However, in most cases the specification
> > >> > does not describe all possible exceptions that may be thrown" case
> > >> > only.
> > >> > In case the spec is complete and not looks like a bug I would vote
> > >> > to follow the spec.
> > >>
> > >> +1 from me.
> > >>
> > >> > Wishes,
> > >>
> > >> --
> > >> 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
> >
> > --
> >
> > 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
--
Chris Gray /k/ Embedded Java Solutions BE0503765045
Embedded & Mobile Java, OSGi http://www.k-embedded-java.com/
chris.gray@kiffer.be +32 3 216 0369
---------------------------------------------------------------------
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] Exception-throwing compatibility question
Posted by Anton Luht <an...@gmail.com>.
Hello,
There's one example that shows that not only code may contain bugs,
but documentation also:
1.5.0 spec [1] says about java.io.BufferedWriter.write(String, int, int)
If the value of the len parameter is negative then no characters are
written. This is contrary to the specification of this method in the
superclass, which requires that an IndexOutOfBoundsException be
thrown.
1.4.2 spec [2] doesn't say this, but 1.4.2 JRE behaves as it was
written according to 1.5 doc. If it is not said, we expect that
BufferedWriter should behave like Writer in this case (throw an
exception) so this behaviour is formally a bug. In fact this is just a
gap in documentation.
[1] http://java.sun.com/j2se/1.5.0/docs/api/java/io/BufferedWriter.html#write(java.lang.String,%20int,%20int)
[2] http://java.sun.com/j2se/1.4.2/docs/api/java/io/BufferedWriter.html#write(java.lang.String,%20int,%20int)
On 7/3/06, Tim Ellison <t....@gmail.com> wrote:
> Mikhail Loenko wrote:
> > For the example I've started this thread with it seems that complying
> > the spec is
> > more appropriate there. But probably there are other examples that
> > caused that the doc was worded the given way
> >
> > George and Tim could you please comment?
>
> What is the concrete example? e.g. are these checked exceptions, ... ?
> or NPE vs. IAE ...
>
> Regards,
> Tim
>
>
> > 2006/6/30, Paulex Yang <pa...@gmail.com>:
> >> Anton Avtamonov wrote:
> >> > On 6/30/06, Mikhail Loenko <ml...@gmail.com> wrote:
> >> >> But section "Exception-throwing compatibility" says that exceptions
> >> >> are different
> >> >> and we aim "to be fully compartible with the RI" "by matching the
> >> >> exception characteristics of each method".
> >> >
> >> > I believe that it is for "However, in most cases the specification
> >> > does not describe all possible exceptions that may be thrown" case
> >> > only.
> >> > In case the spec is complete and not looks like a bug I would vote to
> >> > follow the spec.
> >> +1 from me.
> >> >
> >> > Wishes,
> >>
> >>
> >> --
> >> 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
> >
> >
>
> --
>
> 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
>
>
--
Regards,
Anton Luht,
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] Exception-throwing compatibility question
Posted by Tim Ellison <t....@gmail.com>.
Mikhail Loenko wrote:
> For the example I've started this thread with it seems that complying
> the spec is
> more appropriate there. But probably there are other examples that
> caused that the doc was worded the given way
>
> George and Tim could you please comment?
What is the concrete example? e.g. are these checked exceptions, ... ?
or NPE vs. IAE ...
Regards,
Tim
> 2006/6/30, Paulex Yang <pa...@gmail.com>:
>> Anton Avtamonov wrote:
>> > On 6/30/06, Mikhail Loenko <ml...@gmail.com> wrote:
>> >> But section "Exception-throwing compatibility" says that exceptions
>> >> are different
>> >> and we aim "to be fully compartible with the RI" "by matching the
>> >> exception characteristics of each method".
>> >
>> > I believe that it is for "However, in most cases the specification
>> > does not describe all possible exceptions that may be thrown" case
>> > only.
>> > In case the spec is complete and not looks like a bug I would vote to
>> > follow the spec.
>> +1 from me.
>> >
>> > Wishes,
>>
>>
>> --
>> 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
>
>
--
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] Exception-throwing compatibility question
Posted by Mikhail Loenko <ml...@gmail.com>.
For the example I've started this thread with it seems that complying
the spec is
more appropriate there. But probably there are other examples that
caused that the doc was worded the given way
George and Tim could you please comment?
Thanks,
Mikhail
2006/6/30, Paulex Yang <pa...@gmail.com>:
> Anton Avtamonov wrote:
> > On 6/30/06, Mikhail Loenko <ml...@gmail.com> wrote:
> >> But section "Exception-throwing compatibility" says that exceptions
> >> are different
> >> and we aim "to be fully compartible with the RI" "by matching the
> >> exception characteristics of each method".
> >
> > I believe that it is for "However, in most cases the specification
> > does not describe all possible exceptions that may be thrown" case
> > only.
> > In case the spec is complete and not looks like a bug I would vote to
> > follow the spec.
> +1 from me.
> >
> > Wishes,
>
>
> --
> 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: [classlib] Exception-throwing compatibility question
Posted by Paulex Yang <pa...@gmail.com>.
Anton Avtamonov wrote:
> On 6/30/06, Mikhail Loenko <ml...@gmail.com> wrote:
>> But section "Exception-throwing compatibility" says that exceptions
>> are different
>> and we aim "to be fully compartible with the RI" "by matching the
>> exception characteristics of each method".
>
> I believe that it is for "However, in most cases the specification
> does not describe all possible exceptions that may be thrown" case
> only.
> In case the spec is complete and not looks like a bug I would vote to
> follow the spec.
+1 from me.
>
> Wishes,
--
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: [classlib] Exception-throwing compatibility question
Posted by Anton Avtamonov <an...@gmail.com>.
On 6/30/06, Mikhail Loenko <ml...@gmail.com> wrote:
> But section "Exception-throwing compatibility" says that exceptions
> are different
> and we aim "to be fully compartible with the RI" "by matching the
> exception characteristics of each method".
I believe that it is for "However, in most cases the specification
does not describe all possible exceptions that may be thrown" case
only.
In case the spec is complete and not looks like a bug I would vote to
follow the spec.
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] Exception-throwing compatibility question
Posted by Mikhail Loenko <ml...@gmail.com>.
But section "Exception-throwing compatibility" says that exceptions
are different
and we aim "to be fully compartible with the RI" "by matching the
exception characteristics of each method".
2006/6/30, Paulex Yang <pa...@gmail.com>:
> So I think it is the Rule1 to follow spec if the behavior is clearly
> specified?
>
> Mikhail Loenko wrote:
> > No
> >
> > 2006/6/30, Paulex Yang <pa...@gmail.com>:
> >> Any relationship between Exception1 and Exception2?
> >>
> >> Mikhail Loenko wrote:
> >> > Do I undersyand correctly that even when spec says e.g.
> >> > that Exception1 is thrown when parameter1 == 10 and RI
> >> > throws Exception2 then we follow RI ?
> >> >
> >> > 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
> >> >
> >> >
> >>
> >>
> >> --
> >> 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: [classlib] Exception-throwing compatibility question
Posted by Paulex Yang <pa...@gmail.com>.
So I think it is the Rule1 to follow spec if the behavior is clearly
specified?
Mikhail Loenko wrote:
> No
>
> 2006/6/30, Paulex Yang <pa...@gmail.com>:
>> Any relationship between Exception1 and Exception2?
>>
>> Mikhail Loenko wrote:
>> > Do I undersyand correctly that even when spec says e.g.
>> > that Exception1 is thrown when parameter1 == 10 and RI
>> > throws Exception2 then we follow RI ?
>> >
>> > 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
>> >
>> >
>>
>>
>> --
>> 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: [classlib] Exception-throwing compatibility question
Posted by Mikhail Loenko <ml...@gmail.com>.
No
2006/6/30, Paulex Yang <pa...@gmail.com>:
> Any relationship between Exception1 and Exception2?
>
> Mikhail Loenko wrote:
> > Do I undersyand correctly that even when spec says e.g.
> > that Exception1 is thrown when parameter1 == 10 and RI
> > throws Exception2 then we follow RI ?
> >
> > 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
> >
> >
>
>
> --
> 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: [classlib] Exception-throwing compatibility question
Posted by Paulex Yang <pa...@gmail.com>.
Any relationship between Exception1 and Exception2?
Mikhail Loenko wrote:
> Do I undersyand correctly that even when spec says e.g.
> that Exception1 is thrown when parameter1 == 10 and RI
> throws Exception2 then we follow RI ?
>
> 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
>
>
--
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: [classlib] Exception-throwing compatibility question
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Boris Kuznetsov wrote:
> So, we should always follow RI?
> Even when RI behavior is not consistent and contradicts the spec.?
I never think it's a case of "always". I think it's a case of "always
discuss" :)
geir
>
> Here is one example:
>
> javax.crypto.EncryptedPrivateKeyInfo(algName, encryptedData) spec. states:
> "NoSuchAlgorithmException - if the specified algName is not supported."
>
> For code:
> new EncryptedPrivateKeyInfo(":/. ",new byte[598];
> RI output is
> java.security.NoSuchAlgorithmException: unrecognized algorithm name: 0
> at sun.security.x509.AlgorithmId.get(AlgorithmId.java:105)
> at
> javax.crypto.EncryptedPrivateKeyInfo.<init>(Ljava.lang.String;[B)V(Da
> shoA12275:???)
>
> But the following code produses NumberFormatException on RI
> new EncryptedPrivateKeyInfo(":/. ",new byte[598];
>
> RI output:
> java.lang.NumberFormatException: For input string: ":/"
> at
> java.lang.NumberFormatException.forInputString(NumberFormatException.
> java:48)
> at java.lang.Integer.parseInt(Integer.java:447)
> at java.lang.Integer.valueOf(Integer.java:553)
> at
> sun.security.util.ObjectIdentifier.<init>(ObjectIdentifier.java:69)
> at sun.security.x509.AlgorithmId.algOID(AlgorithmId.java:312)
> at sun.security.x509.AlgorithmId.get(AlgorithmId.java:98)
> at
> javax.crypto.EncryptedPrivateKeyInfo.<init>(Ljava.lang.String;[B)V(Da
> shoA12275:???)
>
> On 7/3/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>> I think that the details should be considered in this, but I'd rather us
>> follow the RI (and log it as a difference from the spec) if we have
>> some inkling that user code will be affected by it.
>>
>> geir
>>
>>
>> Mikhail Loenko wrote:
>> > Do I undersyand correctly that even when spec says e.g.
>> > that Exception1 is thrown when parameter1 == 10 and RI
>> > throws Exception2 then we follow RI ?
>> >
>> > 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] Exception-throwing compatibility question
Posted by Boris Kuznetsov <bo...@gmail.com>.
correction:
RI throws NoSuchAlgorithmException for
new EncryptedPrivateKeyInfo("0", new byte[598]);
On 7/4/06, Boris Kuznetsov <bo...@gmail.com> wrote:
> So, we should always follow RI?
> Even when RI behavior is not consistent and contradicts the spec.?
>
> Here is one example:
>
> javax.crypto.EncryptedPrivateKeyInfo(algName, encryptedData) spec. states:
> "NoSuchAlgorithmException - if the specified algName is not supported."
>
> For code:
> new EncryptedPrivateKeyInfo(":/. ",new byte[598];
> RI output is
> java.security.NoSuchAlgorithmException: unrecognized algorithm name: 0
> at sun.security.x509.AlgorithmId.get(AlgorithmId.java:105)
> at javax.crypto.EncryptedPrivateKeyInfo.<init>(Ljava.lang.String;[B)V(Da
> shoA12275:???)
>
> But the following code produses NumberFormatException on RI
> new EncryptedPrivateKeyInfo(":/. ",new byte[598];
>
> RI output:
> java.lang.NumberFormatException: For input string: ":/"
> at java.lang.NumberFormatException.forInputString(NumberFormatException.
> java:48)
> at java.lang.Integer.parseInt(Integer.java:447)
> at java.lang.Integer.valueOf(Integer.java:553)
> at sun.security.util.ObjectIdentifier.<init>(ObjectIdentifier.java:69)
> at sun.security.x509.AlgorithmId.algOID(AlgorithmId.java:312)
> at sun.security.x509.AlgorithmId.get(AlgorithmId.java:98)
> at javax.crypto.EncryptedPrivateKeyInfo.<init>(Ljava.lang.String;[B)V(Da
> shoA12275:???)
>
> On 7/3/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> > I think that the details should be considered in this, but I'd rather us
> > follow the RI (and log it as a difference from the spec) if we have
> > some inkling that user code will be affected by it.
> >
> > geir
> >
> >
> > Mikhail Loenko wrote:
> > > Do I undersyand correctly that even when spec says e.g.
> > > that Exception1 is thrown when parameter1 == 10 and RI
> > > throws Exception2 then we follow RI ?
> > >
> > > 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
> >
> >
>
>
> --
> Best regards,
> Boris Kuznetsov
> Intel Middleware Products Division
>
--
Best regards,
Boris Kuznetsov
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] Exception-throwing compatibility question
Posted by Boris Kuznetsov <bo...@gmail.com>.
So, we should always follow RI?
Even when RI behavior is not consistent and contradicts the spec.?
Here is one example:
javax.crypto.EncryptedPrivateKeyInfo(algName, encryptedData) spec. states:
"NoSuchAlgorithmException - if the specified algName is not supported."
For code:
new EncryptedPrivateKeyInfo(":/. ",new byte[598];
RI output is
java.security.NoSuchAlgorithmException: unrecognized algorithm name: 0
at sun.security.x509.AlgorithmId.get(AlgorithmId.java:105)
at javax.crypto.EncryptedPrivateKeyInfo.<init>(Ljava.lang.String;[B)V(Da
shoA12275:???)
But the following code produses NumberFormatException on RI
new EncryptedPrivateKeyInfo(":/. ",new byte[598];
RI output:
java.lang.NumberFormatException: For input string: ":/"
at java.lang.NumberFormatException.forInputString(NumberFormatException.
java:48)
at java.lang.Integer.parseInt(Integer.java:447)
at java.lang.Integer.valueOf(Integer.java:553)
at sun.security.util.ObjectIdentifier.<init>(ObjectIdentifier.java:69)
at sun.security.x509.AlgorithmId.algOID(AlgorithmId.java:312)
at sun.security.x509.AlgorithmId.get(AlgorithmId.java:98)
at javax.crypto.EncryptedPrivateKeyInfo.<init>(Ljava.lang.String;[B)V(Da
shoA12275:???)
On 7/3/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> I think that the details should be considered in this, but I'd rather us
> follow the RI (and log it as a difference from the spec) if we have
> some inkling that user code will be affected by it.
>
> geir
>
>
> Mikhail Loenko wrote:
> > Do I undersyand correctly that even when spec says e.g.
> > that Exception1 is thrown when parameter1 == 10 and RI
> > throws Exception2 then we follow RI ?
> >
> > 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
>
>
--
Best regards,
Boris Kuznetsov
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] Exception-throwing compatibility question
Posted by Geir Magnusson Jr <ge...@pobox.com>.
I think that the details should be considered in this, but I'd rather us
follow the RI (and log it as a difference from the spec) if we have
some inkling that user code will be affected by it.
geir
Mikhail Loenko wrote:
> Do I undersyand correctly that even when spec says e.g.
> that Exception1 is thrown when parameter1 == 10 and RI
> throws Exception2 then we follow RI ?
>
> 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