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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>: > > > 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- VP and Chair, Apache Portals (http://portals.apache.org) Apache Software Foundation
signature.asc
Description: Esta parte del mensaje está firmada digitalmente
