Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Subject: Re: [classlib] matching RI exceptions -- are we required to have
	this type of compatibility?
From: Santiago Gala <sgala@apache.org>
To: harmony-dev@incubator.apache.org
In-Reply-To: <23951bd90604240048x38f222d8i3af13aefb6324a31@mail.gmail.com>
References: <906dd82e0604232348h6c0243e6oe3af085d475f4c81@mail.gmail.com>
	 <23951bd90604240015r29de36afpf7871fd0ac60ecb0@mail.gmail.com>
	 <906dd82e0604240027t4df86012vcb60d3bc3611c9f@mail.gmail.com>
	 <23951bd90604240048x38f222d8i3af13aefb6324a31@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature"; boundary="=-v2axaEcZ6ZYwUiN1aNbo"
Organization: Apache Software Foundation
Date: Mon, 24 Apr 2006 12:45:49 +0200
Message-Id: <1145875550.2104.2.camel@localhost>
Mime-Version: 1.0

--=-v2axaEcZ6ZYwUiN1aNbo
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

El lun, 24-04-2006 a las 14:48 +0700, Vladimir Gorr escribi=C3=B3:
> Mikhail,
>=20
> I also thought about this scenario. However, if any TCK tests will fail d=
ue
> to this reason we cannot certify our product. Nobody will talk about the =
invalidity of TCK.
> Most likely we will update our sources.
>=20

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.
>=20
> On 4/24/06, Mikhail Loenko <mloenko@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 spe=
c,
> > 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 <vvgorr@gmail.com>:
> > > The answer to this question (in my opinion) depends on how TCK proces=
ses
> > > 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 <mloenko@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 IndexOutOfBoundsExcepti=
on"
> > 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.or=
g
> > > > 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
> >
> >
--=20
VP and Chair, Apache Portals (http://portals.apache.org)
Apache Software Foundation

--=-v2axaEcZ6ZYwUiN1aNbo
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada
	digitalmente

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQBETKxdZAeG2a2/nhoRAnOPAKCBJ2B0Tqtw8XW/bIw786dFrOkdIwCeKZv/
Tm864my+0rgxf484HkKifWI=
=3z/i
-----END PGP SIGNATURE-----

--=-v2axaEcZ6ZYwUiN1aNbo--