Re: [classlib] Exception-throwing compatibility question
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: Anton Avtamonov wrote: On 6/30/06, Mikhail Loenko [EMAIL PROTECTED] 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: [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] -- Andrew Zhang China Software Development Lab, IBM
Re: [classlib] Exception-throwing compatibility question
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 [EMAIL PROTECTED] 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: [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, Boris Kuznetsov Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Exception-throwing compatibility question
correction: RI throws NoSuchAlgorithmException for new EncryptedPrivateKeyInfo(0, new byte[598]); On 7/4/06, Boris Kuznetsov [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [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, 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Exception-throwing compatibility question
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 [EMAIL PROTECTED] 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: [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]
Re: [classlib] Exception-throwing compatibility question
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 [EMAIL PROTECTED]: Anton Avtamonov wrote: On 6/30/06, Mikhail Loenko [EMAIL PROTECTED] 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: [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] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Exception-throwing compatibility question
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: Anton Avtamonov wrote: On 6/30/06, Mikhail Loenko [EMAIL PROTECTED] 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: [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] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Regards, Anton Luht, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Exception-throwing compatibility question
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: Anton Avtamonov wrote: On 6/30/06, Mikhail Loenko [EMAIL PROTECTED] 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: [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] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Exception-throwing compatibility question
Maybe it's called javadoc bug or spec bug. :) On 7/3/06, Chris Gray [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: Anton Avtamonov wrote: On 6/30/06, Mikhail Loenko [EMAIL PROTECTED] 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: [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] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew Zhang China Software Development Lab, IBM
Re: [classlib] Exception-throwing compatibility question
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Exception-throwing compatibility question
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: [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]
Re: [classlib] Exception-throwing compatibility question
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 [EMAIL PROTECTED]: Anton Avtamonov wrote: On 6/30/06, Mikhail Loenko [EMAIL PROTECTED] 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: [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] -- Richard Liang 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]
Re: [classlib] Exception-throwing compatibility question
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang 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]
Re: [classlib] Exception-throwing compatibility question
No 2006/6/30, Paulex Yang [EMAIL PROTECTED]: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Exception-throwing compatibility question
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 [EMAIL PROTECTED]: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang 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]
Re: [classlib] Exception-throwing compatibility question
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 [EMAIL PROTECTED]: 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 [EMAIL PROTECTED]: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Exception-throwing compatibility question
On 6/30/06, Mikhail Loenko [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Exception-throwing compatibility question
Anton Avtamonov wrote: On 6/30/06, Mikhail Loenko [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Exception-throwing compatibility question
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 [EMAIL PROTECTED]: Anton Avtamonov wrote: On 6/30/06, Mikhail Loenko [EMAIL PROTECTED] 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: [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]
Re: [classlib] Exception-throwing compatibility question
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 [EMAIL PROTECTED]: Anton Avtamonov wrote: On 6/30/06, Mikhail Loenko [EMAIL PROTECTED] 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: [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]
