Re: [classlib][summary] Exception throwing compatibility
Harmony-1170 has been raised to reflect our conclusion. I have attached a patch for site/xdocs/subcomponents/classlibrary/compat.xml Best regards, Richard Richard Liang wrote: Hello All, I'd like to update our Exception-throwing compatibility[1] to reflect our discussion in several threads recently. I just created a wiki page here[2], please kindly comment or update the wiki page directly. If there is no objection, I will provide a patch for site/xdocs/subcomponents/classlibrary/compat.xml Thanks a lot. [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html [2] http://wiki.apache.org/harmony/Exception-throwing_compatibility -- 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][summary] Exception throwing compatibility
Vladimir Ivanov wrote: On 8/9/06, Mikhail Loenko [EMAIL PROTECTED] wrote: 2006/8/9, Richard Liang [EMAIL PROTECTED]: If the spec does not specify which exception is thrown, I think RI *is* compliant with the specification. Am I wrong? I wanted to separate cases when the spec is not clear enough and RI's behavior either hard to reproduce or odd. For example if sqrt(-2) threw exception1, sqrt(-5) threw exception2 and sqrt(-187) threw exception3 The real example is issue 1114 :) Great catch ;-) I have updated the wiki page. Best regards, Richard Thanks, Vladimir 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] -- 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][summary] Exception throwing compatibility
Tim Ellison wrote: We don't have such a JIRA category: If we decide to follow RI, we will raise an Non-bug differences from Spec JIRA. Do you think we need this category to record Harmony's complying-with-RI behavior while breaking the spec? Thanks a lot. Best regards, Richard Do you really need the section starting: We consider RI is compliant with the Java Specification, if RI... Regards, Tim Richard Liang wrote: Hello All, I'd like to update our Exception-throwing compatibility[1] to reflect our discussion in several threads recently. I just created a wiki page here[2], please kindly comment or update the wiki page directly. If there is no objection, I will provide a patch for site/xdocs/subcomponents/classlibrary/compat.xml Thanks a lot. [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html [2] http://wiki.apache.org/harmony/Exception-throwing_compatibility -- Richard Liang China Software Development Lab, IBM
Re: [classlib][summary] Exception throwing compatibility
Richard Liang wrote: Tim Ellison wrote: We don't have such a JIRA category: If we decide to follow RI, we will raise an Non-bug differences from Spec JIRA. Yes. Just thinking about whether we need this category :-) Yes. geir - 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][summary] Exception throwing compatibility
Andrew Zhang wrote: But there are some cases that RI throws an implementation specific exception, we shall throw its public superclass. e.g., If RI throws sun.io.MalformedInputException, we shall throw java.io.CharConversionException. I think it's OK to throw Harmony-implement subclass of the public superclass for some cases? Do you think so? I agree. In fact it says that in the preceding paragraph: Harmony class library code should throw exceptions of the same runtime class (or a subtype of that runtime class) as the RI, other than in cases where the RI throws non-public types whereupon Harmony will throw an exception with the same public supertype. [I'd replace 'should throw' with 'throws' though] Regards, Tim On 8/9/06, Richard Liang [EMAIL PROTECTED] wrote: Hello All, I'd like to update our Exception-throwing compatibility[1] to reflect our discussion in several threads recently. I just created a wiki page here[2], please kindly comment or update the wiki page directly. If there is no objection, I will provide a patch for site/xdocs/subcomponents/classlibrary/compat.xml Thanks a lot. [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html [2] http://wiki.apache.org/harmony/Exception-throwing_compatibility -- 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] -- 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][summary] Exception throwing compatibility
We don't have such a JIRA category: If we decide to follow RI, we will raise an Non-bug differences from Spec JIRA. Do you really need the section starting: We consider RI is compliant with the Java Specification, if RI... Regards, Tim Richard Liang wrote: Hello All, I'd like to update our Exception-throwing compatibility[1] to reflect our discussion in several threads recently. I just created a wiki page here[2], please kindly comment or update the wiki page directly. If there is no objection, I will provide a patch for site/xdocs/subcomponents/classlibrary/compat.xml Thanks a lot. [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html [2] http://wiki.apache.org/harmony/Exception-throwing_compatibility -- 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: Re: [classlib][summary] Exception throwing compatibility
I think that as long as the spec says throws java.x.Y, and we throw a java.x.Y (or an o.a.h subclass of java.x.Y) then that meets the spec. I think the wording could be clearer though; for example, the 'public superclass' is almost certainly meant to be 'an exception in the standard Java class libraries'. For a start, sun.io.MalformedInputException might actually be a subclass of sun.io.GeneralInputException, which has the ACC_PUBLIC bit set (even though it's not a defined class in the Java spec). Perhaps If the exception thrown is a direct instance of an exception from the Java libraries, we will throw the same exception; if it is an instance of an exception not in the Java libraries then we will throw an equivalent o.a.h exception or a parent exception in the Java libraries. It's possible that there's an exception class which is abstract that we must create a subclass for, though off the top of my head I can't think of an abstract exception class in the Java libraries ... Alex. On 09/08/06, Andrew Zhang [EMAIL PROTECTED] wrote: But there are some cases that RI throws an implementation specific exception, we shall throw its public superclass. e.g., If RI throws sun.io.MalformedInputException, we shall throw java.io.CharConversionException. I think it's OK to throw Harmony-implement subclass of the public superclass for some cases? Do you think so? - 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][summary] Exception throwing compatibility
2006/8/9, Tim Ellison [EMAIL PROTECTED]: Andrew Zhang wrote: But there are some cases that RI throws an implementation specific exception, we shall throw its public superclass. e.g., If RI throws sun.io.MalformedInputException, we shall throw java.io.CharConversionException. I think it's OK to throw Harmony-implement subclass of the public superclass for some cases? Do you think so? I agree. In fact it says that in the preceding paragraph: but in the next paragraph it says: If RI is compliant with the Java Specification We shall follow RI's behavior, that is, throws exactly the same exception. I'd mention subclass here too. It might make sense to split If RI is not compliant with the Java Specification to two categories: when we thing the spec does not specify which excactly exception is thrown and when spec does specify but RI throws a different exception Thanks, Mikhail Harmony class library code should throw exceptions of the same runtime class (or a subtype of that runtime class) as the RI, other than in cases where the RI throws non-public types whereupon Harmony will throw an exception with the same public supertype. [I'd replace 'should throw' with 'throws' though] Regards, Tim On 8/9/06, Richard Liang [EMAIL PROTECTED] wrote: Hello All, I'd like to update our Exception-throwing compatibility[1] to reflect our discussion in several threads recently. I just created a wiki page here[2], please kindly comment or update the wiki page directly. If there is no objection, I will provide a patch for site/xdocs/subcomponents/classlibrary/compat.xml Thanks a lot. [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html [2] http://wiki.apache.org/harmony/Exception-throwing_compatibility -- 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] -- 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] - 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][summary] Exception throwing compatibility
Mikhail Loenko wrote: 2006/8/9, Tim Ellison [EMAIL PROTECTED]: Andrew Zhang wrote: But there are some cases that RI throws an implementation specific exception, we shall throw its public superclass. e.g., If RI throws sun.io.MalformedInputException, we shall throw java.io.CharConversionException. I think it's OK to throw Harmony-implement subclass of the public superclass for some cases? Do you think so? I agree. In fact it says that in the preceding paragraph: but in the next paragraph it says: If RI is compliant with the Java Specification We shall follow RI's behavior, that is, throws exactly the same exception. I'd mention subclass here too. I agree. Following RI means throwing the same exception or its subclass. It might make sense to split If RI is not compliant with the Java Specification to two categories: when we thing the spec does not specify which excactly exception is thrown and when spec does specify but RI throws a different exception If the spec does not specify which exception is thrown, I think RI *is* compliant with the specification. Am I wrong? Thanks a lot. Richard. Thanks, Mikhail Harmony class library code should throw exceptions of the same runtime class (or a subtype of that runtime class) as the RI, other than in cases where the RI throws non-public types whereupon Harmony will throw an exception with the same public supertype. [I'd replace 'should throw' with 'throws' though] Regards, Tim On 8/9/06, Richard Liang [EMAIL PROTECTED] wrote: Hello All, I'd like to update our Exception-throwing compatibility[1] to reflect our discussion in several threads recently. I just created a wiki page here[2], please kindly comment or update the wiki page directly. If there is no objection, I will provide a patch for site/xdocs/subcomponents/classlibrary/compat.xml Thanks a lot. [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html [2] http://wiki.apache.org/harmony/Exception-throwing_compatibility -- 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] -- 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] - 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][summary] Exception throwing compatibility
Tim Ellison wrote: Andrew Zhang wrote: But there are some cases that RI throws an implementation specific exception, we shall throw its public superclass. e.g., If RI throws sun.io.MalformedInputException, we shall throw java.io.CharConversionException. I think it's OK to throw Harmony-implement subclass of the public superclass for some cases? Do you think so? I agree. In fact it says that in the preceding paragraph: Harmony class library code should throw exceptions of the same runtime class (or a subtype of that runtime class) as the RI, other than in cases where the RI throws non-public types whereupon Harmony will throw an exception with the same public supertype. [I'd replace 'should throw' with 'throws' though] Thanks a lot, Tim. I will update the wiki page accordingly. Best regards, Richard Regards, Tim On 8/9/06, Richard Liang [EMAIL PROTECTED] wrote: Hello All, I'd like to update our Exception-throwing compatibility[1] to reflect our discussion in several threads recently. I just created a wiki page here[2], please kindly comment or update the wiki page directly. If there is no objection, I will provide a patch for site/xdocs/subcomponents/classlibrary/compat.xml Thanks a lot. [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html [2] http://wiki.apache.org/harmony/Exception-throwing_compatibility -- 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] -- Richard Liang China Software Development Lab, IBM
Re: [classlib][summary] Exception throwing compatibility
Alex Blewitt wrote: I think that as long as the spec says throws java.x.Y, and we throw a java.x.Y (or an o.a.h subclass of java.x.Y) then that meets the spec. Yes. That really complies with the spec. But for Harmony, Complying with spec is not enough. What we are aiming is that user applications would not be broken if they transfer from RI to Harmony. IMHO, we shall try our best to *comply* with RI. Please correct me if I'm wrong. Thanks a lot. I think the wording could be clearer though; for example, the 'public superclass' is almost certainly meant to be 'an exception in the standard Java class libraries'. For a start, sun.io.MalformedInputException might actually be a subclass of sun.io.GeneralInputException, which has the ACC_PUBLIC bit set (even though it's not a defined class in the Java spec). Yes, this description is really confusing. (That's why I post it on wiki page for comments ;-) ) And Perhaps If the exception thrown is a direct instance of an exception from the Java libraries, we will throw the same exception; if it is an instance of an exception not in the Java libraries then we will throw an equivalent o.a.h exception or a parent exception in the Java libraries. It's possible that there's an exception class which is abstract that we must create a subclass for, though off the top of my head I can't think of an abstract exception class in the Java libraries ... Your suggestion sounds better. Thanks a lot, Alex Best regards, Richard Alex. On 09/08/06, Andrew Zhang [EMAIL PROTECTED] wrote: But there are some cases that RI throws an implementation specific exception, we shall throw its public superclass. e.g., If RI throws sun.io.MalformedInputException, we shall throw java.io.CharConversionException. I think it's OK to throw Harmony-implement subclass of the public superclass for some cases? Do you think so? - 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]
