> 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 <[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]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]