Richard Liang wrote:
Geir Magnusson Jr wrote:
Richard Liang wrote:
Geir Magnusson Jr wrote:
Richard Liang wrote:
For this case, I decide to follow useRadix(int radix). Please
correct
me if I'm wrong. Thanks a lot.
Do you mean that you're going to follow the
Geir Magnusson Jr wrote:
Richard Liang wrote:
Geir Magnusson Jr wrote:
Richard Liang wrote:
For this case, I decide to follow useRadix(int radix). Please correct
me if I'm wrong. Thanks a lot.
Do you mean that you're going to follow the spec? If so, we
It seems like the RI is doing random crap, and it wouldn't be something
that someone would depend on... can you imagine?
Easily :) One more example:
Pattern.compile((?![^\\xB5]), Pattern.CASE_INSENSITIVE);
exposes implementation problems:
java.lang.ArrayIndexOutOfBoundsException
at
Richard Liang wrote:
Geir Magnusson Jr wrote:
This is a great example. The last two aren't even legal exceptions for
that method.
It seems like the RI is doing random crap, and it wouldn't be something
that someone would depend on... can you imagine?
Thanks a lot, Geir. There
Richard Liang wrote:
For this case, I decide to follow useRadix(int radix). Please correct
me if I'm wrong. Thanks a lot.
Do you mean that you're going to follow the spec? If so, we should note
that we're making a conscious decision to differ from the RI.
geir
Geir Magnusson Jr wrote:
Richard Liang wrote:
For this case, I decide to follow useRadix(int radix). Please correct
me if I'm wrong. Thanks a lot.
Do you mean that you're going to follow the spec? If so, we should note
that we're making a conscious decision to differ from the RI.
Richard Liang wrote:
Geir Magnusson Jr wrote:
Richard Liang wrote:
For this case, I decide to follow useRadix(int radix). Please correct
me if I'm wrong. Thanks a lot.
Do you mean that you're going to follow the spec? If so, we should note
that we're making a conscious
Hello All,
When I'm trying to implement Scanner.nextInt(int radix), I met a problem.
As we all know, Character.MIN_RADIX equals 2 and Character.MAX_RADIX
equals 36, so the parameter radix can not less than 2 or greater than
36, Otherwise that parameter is illegal.
But on RI, when the
Hi Richard,
Very good example.
You are right, spec says nothing about invalid radix processing for
nextInt(). RI behavior just proves they have no guard check. However
useRadix() produces IAE for the invalid radix and the sound of logic
says that IAE is a proper reaction for wrong radix in any
Paulex Yang wrote:
Richard Liang wrote:
Hello All,
When I'm trying to implement Scanner.nextInt(int radix), I met a
problem.
As we all know, Character.MIN_RADIX equals 2 and Character.MAX_RADIX
equals 36, so the parameter radix can not less than 2 or greater than
36, Otherwise that
Anton Avtamonov wrote:
Hi Richard,
Very good example.
You are right, spec says nothing about invalid radix processing for
nextInt(). RI behavior just proves they have no guard check. However
useRadix() produces IAE for the invalid radix and the sound of logic
says that IAE is a proper
This is a great example. The last two aren't even legal exceptions for
that method.
It seems like the RI is doing random crap, and it wouldn't be something
that someone would depend on... can you imagine?
try {
Scanner.nextInt(foo);
}
catch {StringInxOutOfBndsEx bar) {
... real
On Thursday 06 July 2006 16:49, Geir Magnusson Jr wrote:
This is a great example. The last two aren't even legal exceptions for
that method.
It seems like the RI is doing random crap, and it wouldn't be something
that someone would depend on... can you imagine?
I think we have to
Chris Gray wrote:
On Thursday 06 July 2006 16:49, Geir Magnusson Jr wrote:
This is a great example. The last two aren't even legal exceptions for
that method.
It seems like the RI is doing random crap, and it wouldn't be something
that someone would depend on... can you imagine?
I
Richard Liang wrote:
Paulex Yang wrote:
Richard Liang wrote:
Hello All,
When I'm trying to implement Scanner.nextInt(int radix), I met a
problem.
As we all know, Character.MIN_RADIX equals 2 and Character.MAX_RADIX
equals 36, so the parameter radix can not less than 2 or greater
than
Geir Magnusson Jr wrote:
This is a great example. The last two aren't even legal exceptions for
that method.
It seems like the RI is doing random crap, and it wouldn't be something
that someone would depend on... can you imagine?
Thanks a lot, Geir. There may be a great deal of these
On 7/7/06, Richard Liang [EMAIL PROTECTED] wrote:
SNIP
We may frequently encounter this confused situation, and I suggest we
discuss the problems case by case if someone is not sure how to do. ;-)
For this case, I decide to follow useRadix(int radix). Please correct
me if I'm wrong. Thanks a
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
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
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:
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,
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?
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
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
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
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
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
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
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 :
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
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
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
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
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
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,
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]:
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
I like this solution. If my opinion is counted:
+1 from me.
--
Ivan
Intel Middleware Products Division
2006/5/14, Tim Ellison [EMAIL PROTECTED]:
I agree with your analysis. +1 from me.
Regards,
Tim
Stepan Mishura wrote:
On 5/12/06, *Jimmy, Jing Lv* wrote:
SNIP
In this case,
I agree with your analysis. +1 from me.
Regards,
Tim
Stepan Mishura wrote:
On 5/12/06, *Jimmy, Jing Lv* wrote:
SNIP
In this case, though replace StringIndexOutOfBoundsException with
ArrayIndexOutOfBoundsException is surely better, it seems it is
internal
://java.sun.com/j2se/1.5.0/docs/api/java/lang/StringBuilder.html#insert(
int,%20char)
-Original Message-
From: Mikhail Loenko [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 11, 2006 9:48 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] Exception throwing compatibility
2006/5/12
2006/5/12, Jimmy, Jing Lv [EMAIL PROTECTED]:
Mikhail Fursov wrote:
I agree that the easiest way for us is to throw RI or subclass.
+1.
Is it 'bad' practice to fix this bug (replace subclass with RI) on
user
request and do not think about this problem today?
In this
Stepan Mishura wrote:
On 5/12/06, Jimmy, Jing Lv wrote:
Mikhail Fursov wrote:
I agree that the easiest way for us is to throw RI or subclass.
+1.
Is it 'bad' practice to fix this bug (replace subclass with RI) on
user
request and do not think about this problem today?
In this case,
Note that this is not only beautiful but also performance oriented way -
do not create extra rethrows if it's possible
On 5/12/06, Semukhina, Elena V [EMAIL PROTECTED] wrote:
To have a beautiful fix, why don't you just write
System.arraycopy(data, start, value, 0, count);
without trying
Mikhail Loenko wrote:
2006/5/12, Jimmy, Jing Lv [EMAIL PROTECTED]:
snip
However according to
http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
it has already draw a conclusion that:
1) throw according to spec
2) when we discover RI throw difference exception which
Nathan Beyer wrote:
snip
What is the value in changing the 1 method that throws
StringIndexOutOfBoundsException to ArrayIndexOutOfBoundsException? According
to the compatibility guidelines, first and foremost we follow the
specification. The documented exception (no pun intended) to this rule
More generally, from a performance point of view it is best not to write
if (index 0 || index = array.length || etc. etc.) {
throw new FooIndexOutOfBoundsException();
}
if there is a method call or an array access which will throw the exception
anyway. (Many null parameter checks can be
2006/5/12, Nathan Beyer [EMAIL PROTECTED]:
What is the value in changing the 1 method that throws
StringIndexOutOfBoundsException to ArrayIndexOutOfBoundsException?
The value is that possible user application depending on RI's
behaviour will work with ArrayIndexOutOfBoundsException but will
I have different opinion there.
This exception is quite rare in this function, isn't it? If so, we can
optimize common pass by removing explicit checks. It could be
performance beneficial.
There other point here, internal exception can be lazy exception or
even be optimized out. On DRLVM IMHO if
Chris Gray wrote:
More generally, from a performance point of view it is best not to write
if (index 0 || index = array.length || etc. etc.) {
throw new FooIndexOutOfBoundsException();
}
if there is a method call or an array access which will throw the exception
anyway. (Many null
] Exception throwing compatibility
2006/5/12, Jimmy, Jing Lv [EMAIL PROTECTED]:
Mikhail Fursov wrote:
I agree that the easiest way for us is to throw RI or subclass.
+1.
Is it 'bad' practice to fix this bug (replace subclass with RI) on
user
request and do
On Friday 12 May 2006 11:37, George Harley wrote:
Nathan Beyer wrote:
Note, the RI is NOT throwing ArrayIndexOutOfBoundsExceptions, it is just
letting them happen via invalid array look ups, but in these cases, the
specification is marked with an IndexOutOfBoundsException.
Hi Nathan,
If
2006/5/12, Tim Ellison [EMAIL PROTECTED]:
Mikhail Loenko wrote:
2006/5/12, Jimmy, Jing Lv [EMAIL PROTECTED]:
snip
However according to
http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
it has already draw a conclusion that:
1) throw according to spec
2) when we
2006/5/12, George Harley [EMAIL PROTECTED]:
It sounds like there are as many interpretations of the guidelines as
their are correspondents on this topic :-)
My suggested change would be that we state that Harmony class library
code should throw exceptions of the same runtime class as the RI.
Chris Gray wrote:
On Friday 12 May 2006 11:37, George Harley wrote:
Nathan Beyer wrote:
Note, the RI is NOT throwing ArrayIndexOutOfBoundsExceptions, it is just
letting them happen via invalid array look ups, but in these cases, the
specification is marked with an
Mikhail Loenko wrote:
2006/5/12, George Harley [EMAIL PROTECTED]:
It sounds like there are as many interpretations of the guidelines as
their are correspondents on this topic :-)
My suggested change would be that we state that Harmony class library
code should throw exceptions of the same
Hi George,
2006/5/12, George Harley [EMAIL PROTECTED]:
Mikhail Loenko wrote:
2006/5/12, George Harley [EMAIL PROTECTED]:
It sounds like there are as many interpretations of the guidelines as
their are correspondents on this topic :-)
My suggested change would be that we state that Harmony
Hi,
* Dmitry (who raised the issue) believes that we should change the
Harmony code to throw the type named in the Javadoc/specification (i.e.
the supertype j.l.IndexOutOfBoundsException).
Dmitry is wrong.
* Nathan believes that the code already abides by the specification and
that there
I agree with George and Mikhail that we should throw the same exception with RI.
Do not forget about developers who expects this behaviour. If their
application works OK on RI and fails with
StringIndexOutOfBoundsException on Harmony they will probably return
to RI. Everybody is lazy and do not
George Harley wrote:
Hi,
I would like to start a little discussion around JIRA issue 436 [1]
which deals with exception throwing compatibility between Harmony and
the RI. I feel it is important to reach a concrete agreement on this
as so far all of the participants in the issue seem to
George Harley wrote:
* Little old me thinks that there *is* a problem here but that the
solution is to do as the RI does and throw exceptions with the very same
runtime type as the RI. That's based on my interpretation of the
exception-throwing compatibility guidelines [2], in particular
Hi, George
I agree with your point.
Harmony should throw the same type exception as RI unless we have
sufficient reason such as RI conflict with spec,
or RI's behaviour is illogical or Harmony can't produce the same exception
as RI.
On 5/11/06, George Harley [EMAIL PROTECTED] wrote:
Hi,
I
What is the reason for prohibiting throwing a sub-class?
Every existing try... catch construction will work
Do we really want to convert all tests like
try {
do something
fail();
} catch (SomeException e) {
//expected
}
to something like
try {
do something
fail();
} catch
I agree that the easiest way for us is to throw RI or subclass.
Is it 'bad' practice to fix this bug (replace subclass with RI) on user
request and do not think about this problem today?
On 5/11/06, Richard Liang [EMAIL PROTECTED] wrote:
George Harley wrote:
Hi,
I would like to start a
Mikhail Fursov wrote:
I agree that the easiest way for us is to throw RI or subclass.
+1.
Is it 'bad' practice to fix this bug (replace subclass with RI) on user
request and do not think about this problem today?
In this case, though replace StringIndexOutOfBoundsException with
On 5/12/06, Jimmy, Jing Lv wrote:
Mikhail Fursov wrote:
I agree that the easiest way for us is to throw RI or subclass.
+1.
Is it 'bad' practice to fix this bug (replace subclass with RI) on
user
request and do not think about this problem today?
In this case, though replace
: Thursday, May 11, 2006 9:48 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] Exception throwing compatibility
2006/5/12, Jimmy, Jing Lv [EMAIL PROTECTED]:
Mikhail Fursov wrote:
I agree that the easiest way for us is to throw RI or subclass.
+1.
Is it 'bad' practice
Hi,
I would like to start a little discussion around JIRA issue 436 [1]
which deals with exception throwing compatibility between Harmony and
the RI. I feel it is important to reach a concrete agreement on this as
so far all of the participants in the issue seem to disagree about the
67 matches
Mail list logo
