Re: [classlib] compatibility nuances
Hi,
FYI: I've logged this as HARMONY-953. So now we should not forget about it.
With Best Regards,
2006/7/18, Richard Liang [EMAIL PROTECTED]:
Alexei Zakharov wrote:
I mean this should have about the same priority with the toString()
conversion task discussed in adjacent thread IMHO.
Yes. We could do it *lazily* if there's no objection. ;-)
2006/7/17, Alexei Zakharov [EMAIL PROTECTED]:
IMHO since even BEA VM behave differently in this case we may qualify
this as a low-priority task, rise non-bug JIRA and postpone it until
we meet the real-world app that relies on this. Do nothing is better
than do something that we aren't really sure we should do. :)
Regards,
2006/7/17, Richard Liang [EMAIL PROTECTED]:
Vladimir Gorr wrote:
In this case I'd like to understand what behaviour is correct
and what should be made to satisfy the users. I have no any
preference.
Hello Vladimir,
I think all of us agree that it's possible to following RI's behavior,
Right? The question is we shall decide to follow or not. Any
suggestion?
Thanks a lot.
Best regards,
Richard.
Thanks,
Vladimir.
On 7/14/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Vladimir wrote:
(I believe Alexey used it to test. *Or J9 nevertheless*? IMHO
it needs
to
specify when same discussions start).
I have tried both. And both differ from RI.
Richard wrote:
For getDeclaredMethods(), J9 has the same behavior as RI.
Well, there are some nuances nevertheless. I have wrote a small
test
(that was close to my orginal test) and ran it on four different
VMs.
The test simply does TestBean.class.getDeclaredMethods() and prints
the resulting array.
TestBean.java:
class TestBean {
String methodCalled = null;
public void method(Integer i) {
methodCalled = method1;
}
public void method(int i) {
methodCalled = method2;
}
public void method(boolean b) {
methodCalled = method3;
}
public void method(Boolean b) {
methodCalled = method4;
}
}
The results:
RI (Sun 1.5.0_05)
method int
method boolean
method java.lang.Boolean
method java.lang.Integer
j9 v3
method java.lang.Integer
method int
method boolean
method java.lang.Boolean
DLRVM
method java.lang.Integer
method int
method boolean
method java.lang.Boolean
jrockit-R26.3.0-jdk1.5.0_06
method java.lang.Boolean
method boolean
method int
method java.lang.Integer
With Best Regards,
2006/7/14, Richard Liang [EMAIL PROTECTED]:
Geir Magnusson Jr wrote:
Alexey Varlamov wrote:
2006/7/14, Richard Liang [EMAIL PROTECTED]:
Magnusson, Geir wrote:
-Original Message-
From: Alexei Zakharov [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 13, 2006 10:19 AM
To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED]
Subject: Re: [classlib] compatibility nuances
That our not in any particular
order is different than the not in any particular order
that the RI
does? I'm not trying to make light of it, but it sounds
like all
is
correct.
Right, from the spec point of view everything is correct.
But I'd
like to say that our particular order differs from RI
particular
order
(and such behavior conforms to spec). My next statement is:
there
are
stupid apps that rely on the particular order
returned by RI (regardless of spec). I know one already.
The
question
is: should we care or not?
Can you figure out what their order is? If so, I'd use that
since
we
are free to do what we want, and if someone does depende
on this,
it's
one less change, and it's spec compliant.
As well as I know, the order is what the methods are
declared in
java
source. (Cannot find any document currently ;-) )
IIRC, Sun and JRockit behave differently to this matter,
JRockit's VM
reports methods in reversed order. Besides, there are 2 APIs:
getDeclaredMethods() and getMethods() - we should consider
both
if we
really care. And detecting right order for the last is
tedious -
taking into account variety of heritable methods (declared
directly,
inherited from superclass(es), inherited from
superinterface(s),
inherited from superinterfaces of superclasses).
What does j9 do?
For getDeclaredMethods(), J9 has the same behavior as RI. For
getMethods, J9 and RI behave differently. ;-) But it's not
so hard
to summarize RI's rule of method order. Am I wrong?
Best regards,
Richard
I believe we need a bit stronger motivation for scratching
this
issue,
than a blunt testcase - some real-world application
Re: [classlib] compatibility nuances
Alexei Zakharov wrote:
Vladimir wrote:
(I believe Alexey used it to test. *Or J9 nevertheless*? IMHO it
needs to
specify when same discussions start).
I have tried both. And both differ from RI.
Richard wrote:
For getDeclaredMethods(), J9 has the same behavior as RI.
Well, there are some nuances nevertheless. I have wrote a small test
(that was close to my orginal test) and ran it on four different VMs.
The test simply does TestBean.class.getDeclaredMethods() and prints
the resulting array.
Alexei,
Good catch! I have not tested polymorphism. :-[
Richard
TestBean.java:
class TestBean {
String methodCalled = null;
public void method(Integer i) {
methodCalled = method1;
}
public void method(int i) {
methodCalled = method2;
}
public void method(boolean b) {
methodCalled = method3;
}
public void method(Boolean b) {
methodCalled = method4;
}
}
The results:
RI (Sun 1.5.0_05)
method int
method boolean
method java.lang.Boolean
method java.lang.Integer
j9 v3
method java.lang.Integer
method int
method boolean
method java.lang.Boolean
DLRVM
method java.lang.Integer
method int
method boolean
method java.lang.Boolean
jrockit-R26.3.0-jdk1.5.0_06
method java.lang.Boolean
method boolean
method int
method java.lang.Integer
With Best Regards,
2006/7/14, Richard Liang [EMAIL PROTECTED]:
Geir Magnusson Jr wrote:
Alexey Varlamov wrote:
2006/7/14, Richard Liang [EMAIL PROTECTED]:
Magnusson, Geir wrote:
-Original Message-
From: Alexei Zakharov [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 13, 2006 10:19 AM
To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED]
Subject: Re: [classlib] compatibility nuances
That our not in any particular
order is different than the not in any particular order
that the RI
does? I'm not trying to make light of it, but it sounds like
all is
correct.
Right, from the spec point of view everything is correct. But I'd
like to say that our particular order differs from RI
particular order
(and such behavior conforms to spec). My next statement is:
there are
stupid apps that rely on the particular order
returned by RI (regardless of spec). I know one already. The
question
is: should we care or not?
Can you figure out what their order is? If so, I'd use that
since we
are free to do what we want, and if someone does depende on
this, it's
one less change, and it's spec compliant.
As well as I know, the order is what the methods are declared in
java
source. (Cannot find any document currently ;-) )
IIRC, Sun and JRockit behave differently to this matter, JRockit's VM
reports methods in reversed order. Besides, there are 2 APIs:
getDeclaredMethods() and getMethods() - we should consider both if we
really care. And detecting right order for the last is tedious -
taking into account variety of heritable methods (declared directly,
inherited from superclass(es), inherited from superinterface(s),
inherited from superinterfaces of superclasses).
What does j9 do?
For getDeclaredMethods(), J9 has the same behavior as RI. For
getMethods, J9 and RI behave differently. ;-) But it's not so hard
to summarize RI's rule of method order. Am I wrong?
Best regards,
Richard
I believe we need a bit stronger motivation for scratching this
issue,
than a blunt testcase - some real-world application.
I agree that this isn't a critical issue, but a nice to have. Maybe
we see what J9 does, and follow the majority (if we spend the
time...)?
geir
--
Richard Liang
China Software Development Lab, IBM
--
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] compatibility nuances
Vladimir Gorr wrote:
In this case I'd like to understand what behaviour is correct
and what should be made to satisfy the users. I have no any preference.
Hello Vladimir,
I think all of us agree that it's possible to following RI's behavior,
Right? The question is we shall decide to follow or not. Any suggestion?
Thanks a lot.
Best regards,
Richard.
Thanks,
Vladimir.
On 7/14/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Vladimir wrote:
(I believe Alexey used it to test. *Or J9 nevertheless*? IMHO it needs
to
specify when same discussions start).
I have tried both. And both differ from RI.
Richard wrote:
For getDeclaredMethods(), J9 has the same behavior as RI.
Well, there are some nuances nevertheless. I have wrote a small test
(that was close to my orginal test) and ran it on four different VMs.
The test simply does TestBean.class.getDeclaredMethods() and prints
the resulting array.
TestBean.java:
class TestBean {
String methodCalled = null;
public void method(Integer i) {
methodCalled = method1;
}
public void method(int i) {
methodCalled = method2;
}
public void method(boolean b) {
methodCalled = method3;
}
public void method(Boolean b) {
methodCalled = method4;
}
}
The results:
RI (Sun 1.5.0_05)
method int
method boolean
method java.lang.Boolean
method java.lang.Integer
j9 v3
method java.lang.Integer
method int
method boolean
method java.lang.Boolean
DLRVM
method java.lang.Integer
method int
method boolean
method java.lang.Boolean
jrockit-R26.3.0-jdk1.5.0_06
method java.lang.Boolean
method boolean
method int
method java.lang.Integer
With Best Regards,
2006/7/14, Richard Liang [EMAIL PROTECTED]:
Geir Magnusson Jr wrote:
Alexey Varlamov wrote:
2006/7/14, Richard Liang [EMAIL PROTECTED]:
Magnusson, Geir wrote:
-Original Message-
From: Alexei Zakharov [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 13, 2006 10:19 AM
To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED]
Subject: Re: [classlib] compatibility nuances
That our not in any particular
order is different than the not in any particular order
that the RI
does? I'm not trying to make light of it, but it sounds
like all
is
correct.
Right, from the spec point of view everything is correct.
But I'd
like to say that our particular order differs from RI particular
order
(and such behavior conforms to spec). My next statement is:
there
are
stupid apps that rely on the particular order
returned by RI (regardless of spec). I know one already. The
question
is: should we care or not?
Can you figure out what their order is? If so, I'd use that
since
we
are free to do what we want, and if someone does depende on this,
it's
one less change, and it's spec compliant.
As well as I know, the order is what the methods are declared in
java
source. (Cannot find any document currently ;-) )
IIRC, Sun and JRockit behave differently to this matter,
JRockit's VM
reports methods in reversed order. Besides, there are 2 APIs:
getDeclaredMethods() and getMethods() - we should consider both
if we
really care. And detecting right order for the last is tedious -
taking into account variety of heritable methods (declared
directly,
inherited from superclass(es), inherited from superinterface(s),
inherited from superinterfaces of superclasses).
What does j9 do?
For getDeclaredMethods(), J9 has the same behavior as RI. For
getMethods, J9 and RI behave differently. ;-) But it's not so hard
to summarize RI's rule of method order. Am I wrong?
Best regards,
Richard
I believe we need a bit stronger motivation for scratching this
issue,
than a blunt testcase - some real-world application.
I agree that this isn't a critical issue, but a nice to have.
Maybe
we see what J9 does, and follow the majority (if we spend the
time...)?
geir
--
Richard Liang
China Software Development Lab, IBM
--
Alexei Zakharov,
Intel Middleware Product Division
-
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] compatibility nuances
IMHO since even BEA VM behave differently in this case we may qualify
this as a low-priority task, rise non-bug JIRA and postpone it until
we meet the real-world app that relies on this. Do nothing is better
than do something that we aren't really sure we should do. :)
Regards,
2006/7/17, Richard Liang [EMAIL PROTECTED]:
Vladimir Gorr wrote:
In this case I'd like to understand what behaviour is correct
and what should be made to satisfy the users. I have no any preference.
Hello Vladimir,
I think all of us agree that it's possible to following RI's behavior,
Right? The question is we shall decide to follow or not. Any suggestion?
Thanks a lot.
Best regards,
Richard.
Thanks,
Vladimir.
On 7/14/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Vladimir wrote:
(I believe Alexey used it to test. *Or J9 nevertheless*? IMHO it needs
to
specify when same discussions start).
I have tried both. And both differ from RI.
Richard wrote:
For getDeclaredMethods(), J9 has the same behavior as RI.
Well, there are some nuances nevertheless. I have wrote a small test
(that was close to my orginal test) and ran it on four different VMs.
The test simply does TestBean.class.getDeclaredMethods() and prints
the resulting array.
TestBean.java:
class TestBean {
String methodCalled = null;
public void method(Integer i) {
methodCalled = method1;
}
public void method(int i) {
methodCalled = method2;
}
public void method(boolean b) {
methodCalled = method3;
}
public void method(Boolean b) {
methodCalled = method4;
}
}
The results:
RI (Sun 1.5.0_05)
method int
method boolean
method java.lang.Boolean
method java.lang.Integer
j9 v3
method java.lang.Integer
method int
method boolean
method java.lang.Boolean
DLRVM
method java.lang.Integer
method int
method boolean
method java.lang.Boolean
jrockit-R26.3.0-jdk1.5.0_06
method java.lang.Boolean
method boolean
method int
method java.lang.Integer
With Best Regards,
2006/7/14, Richard Liang [EMAIL PROTECTED]:
Geir Magnusson Jr wrote:
Alexey Varlamov wrote:
2006/7/14, Richard Liang [EMAIL PROTECTED]:
Magnusson, Geir wrote:
-Original Message-
From: Alexei Zakharov [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 13, 2006 10:19 AM
To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED]
Subject: Re: [classlib] compatibility nuances
That our not in any particular
order is different than the not in any particular order
that the RI
does? I'm not trying to make light of it, but it sounds
like all
is
correct.
Right, from the spec point of view everything is correct.
But I'd
like to say that our particular order differs from RI particular
order
(and such behavior conforms to spec). My next statement is:
there
are
stupid apps that rely on the particular order
returned by RI (regardless of spec). I know one already. The
question
is: should we care or not?
Can you figure out what their order is? If so, I'd use that
since
we
are free to do what we want, and if someone does depende on this,
it's
one less change, and it's spec compliant.
As well as I know, the order is what the methods are declared in
java
source. (Cannot find any document currently ;-) )
IIRC, Sun and JRockit behave differently to this matter,
JRockit's VM
reports methods in reversed order. Besides, there are 2 APIs:
getDeclaredMethods() and getMethods() - we should consider both
if we
really care. And detecting right order for the last is tedious -
taking into account variety of heritable methods (declared
directly,
inherited from superclass(es), inherited from superinterface(s),
inherited from superinterfaces of superclasses).
What does j9 do?
For getDeclaredMethods(), J9 has the same behavior as RI. For
getMethods, J9 and RI behave differently. ;-) But it's not so hard
to summarize RI's rule of method order. Am I wrong?
Best regards,
Richard
I believe we need a bit stronger motivation for scratching this
issue,
than a blunt testcase - some real-world application.
I agree that this isn't a critical issue, but a nice to have.
Maybe
we see what J9 does, and follow the majority (if we spend the
time...)?
geir
--
Richard Liang
China Software Development Lab, IBM
--
Alexei Zakharov,
Intel Middleware Product Division
--
Richard Liang
China Software Development Lab, IBM
--
Alexei Zakharov,
Intel Middleware Product 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] compatibility nuances
I mean this should have about the same priority with the toString()
conversion task discussed in adjacent thread IMHO.
2006/7/17, Alexei Zakharov [EMAIL PROTECTED]:
IMHO since even BEA VM behave differently in this case we may qualify
this as a low-priority task, rise non-bug JIRA and postpone it until
we meet the real-world app that relies on this. Do nothing is better
than do something that we aren't really sure we should do. :)
Regards,
2006/7/17, Richard Liang [EMAIL PROTECTED]:
Vladimir Gorr wrote:
In this case I'd like to understand what behaviour is correct
and what should be made to satisfy the users. I have no any preference.
Hello Vladimir,
I think all of us agree that it's possible to following RI's behavior,
Right? The question is we shall decide to follow or not. Any suggestion?
Thanks a lot.
Best regards,
Richard.
Thanks,
Vladimir.
On 7/14/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Vladimir wrote:
(I believe Alexey used it to test. *Or J9 nevertheless*? IMHO it needs
to
specify when same discussions start).
I have tried both. And both differ from RI.
Richard wrote:
For getDeclaredMethods(), J9 has the same behavior as RI.
Well, there are some nuances nevertheless. I have wrote a small test
(that was close to my orginal test) and ran it on four different VMs.
The test simply does TestBean.class.getDeclaredMethods() and prints
the resulting array.
TestBean.java:
class TestBean {
String methodCalled = null;
public void method(Integer i) {
methodCalled = method1;
}
public void method(int i) {
methodCalled = method2;
}
public void method(boolean b) {
methodCalled = method3;
}
public void method(Boolean b) {
methodCalled = method4;
}
}
The results:
RI (Sun 1.5.0_05)
method int
method boolean
method java.lang.Boolean
method java.lang.Integer
j9 v3
method java.lang.Integer
method int
method boolean
method java.lang.Boolean
DLRVM
method java.lang.Integer
method int
method boolean
method java.lang.Boolean
jrockit-R26.3.0-jdk1.5.0_06
method java.lang.Boolean
method boolean
method int
method java.lang.Integer
With Best Regards,
2006/7/14, Richard Liang [EMAIL PROTECTED]:
Geir Magnusson Jr wrote:
Alexey Varlamov wrote:
2006/7/14, Richard Liang [EMAIL PROTECTED]:
Magnusson, Geir wrote:
-Original Message-
From: Alexei Zakharov [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 13, 2006 10:19 AM
To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED]
Subject: Re: [classlib] compatibility nuances
That our not in any particular
order is different than the not in any particular order
that the RI
does? I'm not trying to make light of it, but it sounds
like all
is
correct.
Right, from the spec point of view everything is correct.
But I'd
like to say that our particular order differs from RI particular
order
(and such behavior conforms to spec). My next statement is:
there
are
stupid apps that rely on the particular order
returned by RI (regardless of spec). I know one already. The
question
is: should we care or not?
Can you figure out what their order is? If so, I'd use that
since
we
are free to do what we want, and if someone does depende on this,
it's
one less change, and it's spec compliant.
As well as I know, the order is what the methods are declared in
java
source. (Cannot find any document currently ;-) )
IIRC, Sun and JRockit behave differently to this matter,
JRockit's VM
reports methods in reversed order. Besides, there are 2 APIs:
getDeclaredMethods() and getMethods() - we should consider both
if we
really care. And detecting right order for the last is tedious -
taking into account variety of heritable methods (declared
directly,
inherited from superclass(es), inherited from superinterface(s),
inherited from superinterfaces of superclasses).
What does j9 do?
For getDeclaredMethods(), J9 has the same behavior as RI. For
getMethods, J9 and RI behave differently. ;-) But it's not so hard
to summarize RI's rule of method order. Am I wrong?
Best regards,
Richard
I believe we need a bit stronger motivation for scratching this
issue,
than a blunt testcase - some real-world application.
I agree that this isn't a critical issue, but a nice to have.
Maybe
we see what J9 does, and follow the majority (if we spend the
time...)?
geir
--
Richard Liang
China Software Development Lab, IBM
--
Alexei Zakharov,
Intel Middleware Product Division
--
Richard Liang
China Software Development Lab, IBM
--
Alexei Zakharov,
Intel Middleware Product Division
Re: [classlib] compatibility nuances
Alexei Zakharov wrote:
I mean this should have about the same priority with the toString()
conversion task discussed in adjacent thread IMHO.
Yes. We could do it *lazily* if there's no objection. ;-)
2006/7/17, Alexei Zakharov [EMAIL PROTECTED]:
IMHO since even BEA VM behave differently in this case we may qualify
this as a low-priority task, rise non-bug JIRA and postpone it until
we meet the real-world app that relies on this. Do nothing is better
than do something that we aren't really sure we should do. :)
Regards,
2006/7/17, Richard Liang [EMAIL PROTECTED]:
Vladimir Gorr wrote:
In this case I'd like to understand what behaviour is correct
and what should be made to satisfy the users. I have no any
preference.
Hello Vladimir,
I think all of us agree that it's possible to following RI's behavior,
Right? The question is we shall decide to follow or not. Any
suggestion?
Thanks a lot.
Best regards,
Richard.
Thanks,
Vladimir.
On 7/14/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Vladimir wrote:
(I believe Alexey used it to test. *Or J9 nevertheless*? IMHO
it needs
to
specify when same discussions start).
I have tried both. And both differ from RI.
Richard wrote:
For getDeclaredMethods(), J9 has the same behavior as RI.
Well, there are some nuances nevertheless. I have wrote a small
test
(that was close to my orginal test) and ran it on four different
VMs.
The test simply does TestBean.class.getDeclaredMethods() and prints
the resulting array.
TestBean.java:
class TestBean {
String methodCalled = null;
public void method(Integer i) {
methodCalled = method1;
}
public void method(int i) {
methodCalled = method2;
}
public void method(boolean b) {
methodCalled = method3;
}
public void method(Boolean b) {
methodCalled = method4;
}
}
The results:
RI (Sun 1.5.0_05)
method int
method boolean
method java.lang.Boolean
method java.lang.Integer
j9 v3
method java.lang.Integer
method int
method boolean
method java.lang.Boolean
DLRVM
method java.lang.Integer
method int
method boolean
method java.lang.Boolean
jrockit-R26.3.0-jdk1.5.0_06
method java.lang.Boolean
method boolean
method int
method java.lang.Integer
With Best Regards,
2006/7/14, Richard Liang [EMAIL PROTECTED]:
Geir Magnusson Jr wrote:
Alexey Varlamov wrote:
2006/7/14, Richard Liang [EMAIL PROTECTED]:
Magnusson, Geir wrote:
-Original Message-
From: Alexei Zakharov [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 13, 2006 10:19 AM
To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED]
Subject: Re: [classlib] compatibility nuances
That our not in any particular
order is different than the not in any particular order
that the RI
does? I'm not trying to make light of it, but it sounds
like all
is
correct.
Right, from the spec point of view everything is correct.
But I'd
like to say that our particular order differs from RI
particular
order
(and such behavior conforms to spec). My next statement is:
there
are
stupid apps that rely on the particular order
returned by RI (regardless of spec). I know one already.
The
question
is: should we care or not?
Can you figure out what their order is? If so, I'd use that
since
we
are free to do what we want, and if someone does depende
on this,
it's
one less change, and it's spec compliant.
As well as I know, the order is what the methods are
declared in
java
source. (Cannot find any document currently ;-) )
IIRC, Sun and JRockit behave differently to this matter,
JRockit's VM
reports methods in reversed order. Besides, there are 2 APIs:
getDeclaredMethods() and getMethods() - we should consider
both
if we
really care. And detecting right order for the last is
tedious -
taking into account variety of heritable methods (declared
directly,
inherited from superclass(es), inherited from
superinterface(s),
inherited from superinterfaces of superclasses).
What does j9 do?
For getDeclaredMethods(), J9 has the same behavior as RI. For
getMethods, J9 and RI behave differently. ;-) But it's not
so hard
to summarize RI's rule of method order. Am I wrong?
Best regards,
Richard
I believe we need a bit stronger motivation for scratching
this
issue,
than a blunt testcase - some real-world application.
I agree that this isn't a critical issue, but a nice to have.
Maybe
we see what J9 does, and follow the majority (if we spend the
time...)?
geir
--
Richard Liang
China Software Development Lab, IBM
--
Alexei Zakharov,
Intel Middleware Product Division
Re: [classlib] compatibility nuances
Vladimir Gorr wrote: On 7/14/06, Alexey Varlamov [EMAIL PROTECTED] wrote: 2006/7/14, Richard Liang [EMAIL PROTECTED]: Magnusson, Geir wrote: -Original Message- From: Alexei Zakharov [mailto:[EMAIL PROTECTED] Sent: Thursday, July 13, 2006 10:19 AM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: Re: [classlib] compatibility nuances That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. Right, from the spec point of view everything is correct. But I'd like to say that our particular order differs from RI particular order (and such behavior conforms to spec). My next statement is: there are stupid apps that rely on the particular order returned by RI (regardless of spec). I know one already. The question is: should we care or not? Can you figure out what their order is? If so, I'd use that since we are free to do what we want, and if someone does depende on this, it's one less change, and it's spec compliant. As well as I know, the order is what the methods are declared in java source. (Cannot find any document currently ;-) ) IIRC, Sun and JRockit behave differently to this matter, JRockit's VM reports methods in reversed order. Besides, there are 2 APIs: getDeclaredMethods() and getMethods() - we should consider both if we really care. And detecting right order for the last is tedious - taking into account variety of heritable methods (declared directly, inherited from superclass(es), inherited from superinterface(s), inherited from superinterfaces of superclasses). What does IBM do? I agree with this assertion. The implementation of kernel classes for DRLVM was clean room one. There's no doubt about that. (I believe Alexey used it to test. *Or J9 nevertheless*? IMHO it needs to specify when same discussions start). We've knew nothing about the algorithms used by RI. All we knew is our implementation should correspond to the specifications and not break them. The case discussed here is such one in my opinion. Could you please give prove why the compatibility needs here? Just convenience for users. What RI should be used for this purpose if any? Thanks, Vladimir. I believe we need a bit stronger motivation for scratching this issue, than a blunt testcase - some real-world application. -- Regards, Alexey Varlamov Best regards, Richard Geir 2006/7/13, Geir Magnusson Jr [EMAIL PROTECTED]: I assume you mean [drlvm], since java.lang.Class in [classlib] is just a stub, right? Anyway, what would you say exactly? That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. geir Alexei Zakharov wrote: Hi, I have discovered we have small incompatibility in our java.lang.Class implementation. The order of elements returned by Class.getDeclaredMethods() differs from RI. The spec says here: The elements in the array returned are not sorted and are not in any particular order. But I already know one application that relies on this - this was one of java.beans test (already patched). I don't want to say this is somehow bad but still like to inform the community about this issue. Probably we need to rise non-bug differences JIRA? Thanks, -- Alexei Zakharov, Intel Middleware Product Division - 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] - 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] compatibility nuances
Alexey Varlamov wrote: 2006/7/14, Richard Liang [EMAIL PROTECTED]: Magnusson, Geir wrote: -Original Message- From: Alexei Zakharov [mailto:[EMAIL PROTECTED] Sent: Thursday, July 13, 2006 10:19 AM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: Re: [classlib] compatibility nuances That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. Right, from the spec point of view everything is correct. But I'd like to say that our particular order differs from RI particular order (and such behavior conforms to spec). My next statement is: there are stupid apps that rely on the particular order returned by RI (regardless of spec). I know one already. The question is: should we care or not? Can you figure out what their order is? If so, I'd use that since we are free to do what we want, and if someone does depende on this, it's one less change, and it's spec compliant. As well as I know, the order is what the methods are declared in java source. (Cannot find any document currently ;-) ) IIRC, Sun and JRockit behave differently to this matter, JRockit's VM reports methods in reversed order. Besides, there are 2 APIs: getDeclaredMethods() and getMethods() - we should consider both if we really care. And detecting right order for the last is tedious - taking into account variety of heritable methods (declared directly, inherited from superclass(es), inherited from superinterface(s), inherited from superinterfaces of superclasses). What does j9 do? I believe we need a bit stronger motivation for scratching this issue, than a blunt testcase - some real-world application. I agree that this isn't a critical issue, but a nice to have. Maybe we see what J9 does, and follow the majority (if we spend the time...)? 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] compatibility nuances
Geir Magnusson Jr wrote: Alexey Varlamov wrote: 2006/7/14, Richard Liang [EMAIL PROTECTED]: Magnusson, Geir wrote: -Original Message- From: Alexei Zakharov [mailto:[EMAIL PROTECTED] Sent: Thursday, July 13, 2006 10:19 AM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: Re: [classlib] compatibility nuances That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. Right, from the spec point of view everything is correct. But I'd like to say that our particular order differs from RI particular order (and such behavior conforms to spec). My next statement is: there are stupid apps that rely on the particular order returned by RI (regardless of spec). I know one already. The question is: should we care or not? Can you figure out what their order is? If so, I'd use that since we are free to do what we want, and if someone does depende on this, it's one less change, and it's spec compliant. As well as I know, the order is what the methods are declared in java source. (Cannot find any document currently ;-) ) IIRC, Sun and JRockit behave differently to this matter, JRockit's VM reports methods in reversed order. Besides, there are 2 APIs: getDeclaredMethods() and getMethods() - we should consider both if we really care. And detecting right order for the last is tedious - taking into account variety of heritable methods (declared directly, inherited from superclass(es), inherited from superinterface(s), inherited from superinterfaces of superclasses). What does j9 do? For getDeclaredMethods(), J9 has the same behavior as RI. For getMethods, J9 and RI behave differently. ;-) But it's not so hard to summarize RI's rule of method order. Am I wrong? Best regards, Richard I believe we need a bit stronger motivation for scratching this issue, than a blunt testcase - some real-world application. I agree that this isn't a critical issue, but a nice to have. Maybe we see what J9 does, and follow the majority (if we spend the time...)? geir - 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] compatibility nuances
Vladimir wrote:
(I believe Alexey used it to test. *Or J9 nevertheless*? IMHO it needs to
specify when same discussions start).
I have tried both. And both differ from RI.
Richard wrote:
For getDeclaredMethods(), J9 has the same behavior as RI.
Well, there are some nuances nevertheless. I have wrote a small test
(that was close to my orginal test) and ran it on four different VMs.
The test simply does TestBean.class.getDeclaredMethods() and prints
the resulting array.
TestBean.java:
class TestBean {
String methodCalled = null;
public void method(Integer i) {
methodCalled = method1;
}
public void method(int i) {
methodCalled = method2;
}
public void method(boolean b) {
methodCalled = method3;
}
public void method(Boolean b) {
methodCalled = method4;
}
}
The results:
RI (Sun 1.5.0_05)
method int
method boolean
method java.lang.Boolean
method java.lang.Integer
j9 v3
method java.lang.Integer
method int
method boolean
method java.lang.Boolean
DLRVM
method java.lang.Integer
method int
method boolean
method java.lang.Boolean
jrockit-R26.3.0-jdk1.5.0_06
method java.lang.Boolean
method boolean
method int
method java.lang.Integer
With Best Regards,
2006/7/14, Richard Liang [EMAIL PROTECTED]:
Geir Magnusson Jr wrote:
Alexey Varlamov wrote:
2006/7/14, Richard Liang [EMAIL PROTECTED]:
Magnusson, Geir wrote:
-Original Message-
From: Alexei Zakharov [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 13, 2006 10:19 AM
To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED]
Subject: Re: [classlib] compatibility nuances
That our not in any particular
order is different than the not in any particular order
that the RI
does? I'm not trying to make light of it, but it sounds like all is
correct.
Right, from the spec point of view everything is correct. But I'd
like to say that our particular order differs from RI particular order
(and such behavior conforms to spec). My next statement is: there are
stupid apps that rely on the particular order
returned by RI (regardless of spec). I know one already. The question
is: should we care or not?
Can you figure out what their order is? If so, I'd use that since we
are free to do what we want, and if someone does depende on this, it's
one less change, and it's spec compliant.
As well as I know, the order is what the methods are declared in java
source. (Cannot find any document currently ;-) )
IIRC, Sun and JRockit behave differently to this matter, JRockit's VM
reports methods in reversed order. Besides, there are 2 APIs:
getDeclaredMethods() and getMethods() - we should consider both if we
really care. And detecting right order for the last is tedious -
taking into account variety of heritable methods (declared directly,
inherited from superclass(es), inherited from superinterface(s),
inherited from superinterfaces of superclasses).
What does j9 do?
For getDeclaredMethods(), J9 has the same behavior as RI. For
getMethods, J9 and RI behave differently. ;-) But it's not so hard
to summarize RI's rule of method order. Am I wrong?
Best regards,
Richard
I believe we need a bit stronger motivation for scratching this issue,
than a blunt testcase - some real-world application.
I agree that this isn't a critical issue, but a nice to have. Maybe
we see what J9 does, and follow the majority (if we spend the time...)?
geir
--
Richard Liang
China Software Development Lab, IBM
--
Alexei Zakharov,
Intel Middleware Product 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] compatibility nuances
In this case I'd like to understand what behaviour is correct
and what should be made to satisfy the users. I have no any preference.
Thanks,
Vladimir.
On 7/14/06, Alexei Zakharov [EMAIL PROTECTED] wrote:
Vladimir wrote:
(I believe Alexey used it to test. *Or J9 nevertheless*? IMHO it needs
to
specify when same discussions start).
I have tried both. And both differ from RI.
Richard wrote:
For getDeclaredMethods(), J9 has the same behavior as RI.
Well, there are some nuances nevertheless. I have wrote a small test
(that was close to my orginal test) and ran it on four different VMs.
The test simply does TestBean.class.getDeclaredMethods() and prints
the resulting array.
TestBean.java:
class TestBean {
String methodCalled = null;
public void method(Integer i) {
methodCalled = method1;
}
public void method(int i) {
methodCalled = method2;
}
public void method(boolean b) {
methodCalled = method3;
}
public void method(Boolean b) {
methodCalled = method4;
}
}
The results:
RI (Sun 1.5.0_05)
method int
method boolean
method java.lang.Boolean
method java.lang.Integer
j9 v3
method java.lang.Integer
method int
method boolean
method java.lang.Boolean
DLRVM
method java.lang.Integer
method int
method boolean
method java.lang.Boolean
jrockit-R26.3.0-jdk1.5.0_06
method java.lang.Boolean
method boolean
method int
method java.lang.Integer
With Best Regards,
2006/7/14, Richard Liang [EMAIL PROTECTED]:
Geir Magnusson Jr wrote:
Alexey Varlamov wrote:
2006/7/14, Richard Liang [EMAIL PROTECTED]:
Magnusson, Geir wrote:
-Original Message-
From: Alexei Zakharov [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 13, 2006 10:19 AM
To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED]
Subject: Re: [classlib] compatibility nuances
That our not in any particular
order is different than the not in any particular order
that the RI
does? I'm not trying to make light of it, but it sounds like all
is
correct.
Right, from the spec point of view everything is correct. But I'd
like to say that our particular order differs from RI particular
order
(and such behavior conforms to spec). My next statement is: there
are
stupid apps that rely on the particular order
returned by RI (regardless of spec). I know one already. The
question
is: should we care or not?
Can you figure out what their order is? If so, I'd use that since
we
are free to do what we want, and if someone does depende on this,
it's
one less change, and it's spec compliant.
As well as I know, the order is what the methods are declared in
java
source. (Cannot find any document currently ;-) )
IIRC, Sun and JRockit behave differently to this matter, JRockit's VM
reports methods in reversed order. Besides, there are 2 APIs:
getDeclaredMethods() and getMethods() - we should consider both if we
really care. And detecting right order for the last is tedious -
taking into account variety of heritable methods (declared directly,
inherited from superclass(es), inherited from superinterface(s),
inherited from superinterfaces of superclasses).
What does j9 do?
For getDeclaredMethods(), J9 has the same behavior as RI. For
getMethods, J9 and RI behave differently. ;-) But it's not so hard
to summarize RI's rule of method order. Am I wrong?
Best regards,
Richard
I believe we need a bit stronger motivation for scratching this
issue,
than a blunt testcase - some real-world application.
I agree that this isn't a critical issue, but a nice to have. Maybe
we see what J9 does, and follow the majority (if we spend the
time...)?
geir
--
Richard Liang
China Software Development Lab, IBM
--
Alexei Zakharov,
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] compatibility nuances
Hi, I have discovered we have small incompatibility in our java.lang.Class implementation. The order of elements returned by Class.getDeclaredMethods() differs from RI. The spec says here: The elements in the array returned are not sorted and are not in any particular order. But I already know one application that relies on this - this was one of java.beans test (already patched). I don't want to say this is somehow bad but still like to inform the community about this issue. Probably we need to rise non-bug differences JIRA? Thanks, -- Alexei Zakharov, Intel Middleware Product 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] compatibility nuances
I assume you mean [drlvm], since java.lang.Class in [classlib] is just a stub, right? Anyway, what would you say exactly? That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. geir Alexei Zakharov wrote: Hi, I have discovered we have small incompatibility in our java.lang.Class implementation. The order of elements returned by Class.getDeclaredMethods() differs from RI. The spec says here: The elements in the array returned are not sorted and are not in any particular order. But I already know one application that relies on this - this was one of java.beans test (already patched). I don't want to say this is somehow bad but still like to inform the community about this issue. Probably we need to rise non-bug differences JIRA? Thanks, - 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] compatibility nuances
On 7/13/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: I assume you mean [drlvm], since java.lang.Class in [classlib] is just a stub, right? Anyway, what would you say exactly? That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. IMHO, If Harmony VM could act the same as that of RI, the thing would be better. geir Alexei Zakharov wrote: Hi, I have discovered we have small incompatibility in our java.lang.Class implementation. The order of elements returned by Class.getDeclaredMethods() differs from RI. The spec says here: The elements in the array returned are not sorted and are not in any particular order. But I already know one application that relies on this - this was one of java.beans test (already patched). I don't want to say this is somehow bad but still like to inform the community about this issue. Probably we need to rise non-bug differences JIRA? Thanks, - 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] compatibility nuances
-Original Message- From: Andrew Zhang [mailto:[EMAIL PROTECTED] Sent: Thursday, July 13, 2006 10:04 AM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: Re: [classlib] compatibility nuances On 7/13/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: I assume you mean [drlvm], since java.lang.Class in [classlib] is just a stub, right? Anyway, what would you say exactly? That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. IMHO, If Harmony VM could act the same as that of RI, the thing would be better. I agree, but is their order predictable? 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] compatibility nuances
That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. Right, from the spec point of view everything is correct. But I'd like to say that our particular order differs from RI particular order (and such behavior conforms to spec). My next statement is: there are stupid apps that rely on the particular order returned by RI (regardless of spec). I know one already. The question is: should we care or not? 2006/7/13, Geir Magnusson Jr [EMAIL PROTECTED]: I assume you mean [drlvm], since java.lang.Class in [classlib] is just a stub, right? Anyway, what would you say exactly? That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. geir Alexei Zakharov wrote: Hi, I have discovered we have small incompatibility in our java.lang.Class implementation. The order of elements returned by Class.getDeclaredMethods() differs from RI. The spec says here: The elements in the array returned are not sorted and are not in any particular order. But I already know one application that relies on this - this was one of java.beans test (already patched). I don't want to say this is somehow bad but still like to inform the community about this issue. Probably we need to rise non-bug differences JIRA? Thanks, -- Alexei Zakharov, Intel Middleware Product 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] compatibility nuances
-Original Message- From: Alexei Zakharov [mailto:[EMAIL PROTECTED] Sent: Thursday, July 13, 2006 10:19 AM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: Re: [classlib] compatibility nuances That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. Right, from the spec point of view everything is correct. But I'd like to say that our particular order differs from RI particular order (and such behavior conforms to spec). My next statement is: there are stupid apps that rely on the particular order returned by RI (regardless of spec). I know one already. The question is: should we care or not? Can you figure out what their order is? If so, I'd use that since we are free to do what we want, and if someone does depende on this, it's one less change, and it's spec compliant. Geir 2006/7/13, Geir Magnusson Jr [EMAIL PROTECTED]: I assume you mean [drlvm], since java.lang.Class in [classlib] is just a stub, right? Anyway, what would you say exactly? That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. geir Alexei Zakharov wrote: Hi, I have discovered we have small incompatibility in our java.lang.Class implementation. The order of elements returned by Class.getDeclaredMethods() differs from RI. The spec says here: The elements in the array returned are not sorted and are not in any particular order. But I already know one application that relies on this - this was one of java.beans test (already patched). I don't want to say this is somehow bad but still like to inform the community about this issue. Probably we need to rise non-bug differences JIRA? Thanks, -- Alexei Zakharov, Intel Middleware Product Division - 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] compatibility nuances
On 7/13/06, Magnusson, Geir [EMAIL PROTECTED] wrote: -Original Message- From: Alexei Zakharov [mailto:[EMAIL PROTECTED] Sent: Thursday, July 13, 2006 10:19 AM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: Re: [classlib] compatibility nuances That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. Right, from the spec point of view everything is correct. But I'd like to say that our particular order differs from RI particular order (and such behavior conforms to spec). My next statement is: there are stupid apps that rely on the particular order returned by RI (regardless of spec). I know one already. The question is: should we care or not? Can you figure out what their order is? If so, I'd use that since we are free to do what we want, and if someone does depende on this, it's one less change, and it's spec compliant. +1. Do our best to comply with spec and follow RI :) Geir 2006/7/13, Geir Magnusson Jr [EMAIL PROTECTED]: I assume you mean [drlvm], since java.lang.Class in [classlib] is just a stub, right? Anyway, what would you say exactly? That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. geir Alexei Zakharov wrote: Hi, I have discovered we have small incompatibility in our java.lang.Class implementation. The order of elements returned by Class.getDeclaredMethods() differs from RI. The spec says here: The elements in the array returned are not sorted and are not in any particular order. But I already know one application that relies on this - this was one of java.beans test (already patched). I don't want to say this is somehow bad but still like to inform the community about this issue. Probably we need to rise non-bug differences JIRA? Thanks, -- Alexei Zakharov, Intel Middleware Product Division - 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] compatibility nuances
Can you figure out what their order is? If so, I'd use that since we are free to do what we want, and if someone does depende on this, it's one less change, and it's spec compliant. I would say it is in the definition order but some methods are placed in the begining of the list by no reason. Example of such methods: public static void main() public static Test suite() The only thing I can say with confidence - the order doesn't change from invocation to invocation. +1. Do our best to comply with spec and follow RI :) Yeah, probably a good idea. Any volunteers? :) 2006/7/13, Andrew Zhang [EMAIL PROTECTED]: On 7/13/06, Magnusson, Geir [EMAIL PROTECTED] wrote: -Original Message- From: Alexei Zakharov [mailto:[EMAIL PROTECTED] Sent: Thursday, July 13, 2006 10:19 AM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: Re: [classlib] compatibility nuances That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. Right, from the spec point of view everything is correct. But I'd like to say that our particular order differs from RI particular order (and such behavior conforms to spec). My next statement is: there are stupid apps that rely on the particular order returned by RI (regardless of spec). I know one already. The question is: should we care or not? Can you figure out what their order is? If so, I'd use that since we are free to do what we want, and if someone does depende on this, it's one less change, and it's spec compliant. +1. Do our best to comply with spec and follow RI :) Geir 2006/7/13, Geir Magnusson Jr [EMAIL PROTECTED]: I assume you mean [drlvm], since java.lang.Class in [classlib] is just a stub, right? Anyway, what would you say exactly? That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. geir Alexei Zakharov wrote: Hi, I have discovered we have small incompatibility in our java.lang.Class implementation. The order of elements returned by Class.getDeclaredMethods() differs from RI. The spec says here: The elements in the array returned are not sorted and are not in any particular order. But I already know one application that relies on this - this was one of java.beans test (already patched). I don't want to say this is somehow bad but still like to inform the community about this issue. Probably we need to rise non-bug differences JIRA? Thanks, -- Alexei Zakharov, Intel Middleware Product Division -- Alexei Zakharov, Intel Middleware Product 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] compatibility nuances
Alexei Zakharov wrote: I know one already. Go on, stop teasing, what is it? ;-) As others have said elsewhere, if you can determine the order, and we don't have to perform unnatural acts to make it the same, then no reason to be different just because we can. Regards, Tim -- 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] compatibility nuances
Go on, stop teasing, what is it? ;-) Not a big deal, I have already mentioned it in my first mail. This is our java.beans tests. :-) The idea was if one person hit upon the idea of such tests then another person can similarly build a complete application based on the same precondition. 2006/7/13, Tim Ellison [EMAIL PROTECTED]: Alexei Zakharov wrote: I know one already. Go on, stop teasing, what is it? ;-) As others have said elsewhere, if you can determine the order, and we don't have to perform unnatural acts to make it the same, then no reason to be different just because we can. Regards, Tim -- 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] -- Alexei Zakharov, Intel Middleware Product 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] compatibility nuances
Magnusson, Geir wrote: -Original Message- From: Alexei Zakharov [mailto:[EMAIL PROTECTED] Sent: Thursday, July 13, 2006 10:19 AM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: Re: [classlib] compatibility nuances That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. Right, from the spec point of view everything is correct. But I'd like to say that our particular order differs from RI particular order (and such behavior conforms to spec). My next statement is: there are stupid apps that rely on the particular order returned by RI (regardless of spec). I know one already. The question is: should we care or not? Can you figure out what their order is? If so, I'd use that since we are free to do what we want, and if someone does depende on this, it's one less change, and it's spec compliant. As well as I know, the order is what the methods are declared in java source. (Cannot find any document currently ;-) ) Best regards, Richard Geir 2006/7/13, Geir Magnusson Jr [EMAIL PROTECTED]: I assume you mean [drlvm], since java.lang.Class in [classlib] is just a stub, right? Anyway, what would you say exactly? That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. geir Alexei Zakharov wrote: Hi, I have discovered we have small incompatibility in our java.lang.Class implementation. The order of elements returned by Class.getDeclaredMethods() differs from RI. The spec says here: The elements in the array returned are not sorted and are not in any particular order. But I already know one application that relies on this - this was one of java.beans test (already patched). I don't want to say this is somehow bad but still like to inform the community about this issue. Probably we need to rise non-bug differences JIRA? Thanks, -- Alexei Zakharov, Intel Middleware Product Division - 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
Re: [classlib] compatibility nuances
On 7/14/06, Alexey Varlamov [EMAIL PROTECTED] wrote: 2006/7/14, Richard Liang [EMAIL PROTECTED]: Magnusson, Geir wrote: -Original Message- From: Alexei Zakharov [mailto:[EMAIL PROTECTED] Sent: Thursday, July 13, 2006 10:19 AM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: Re: [classlib] compatibility nuances That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. Right, from the spec point of view everything is correct. But I'd like to say that our particular order differs from RI particular order (and such behavior conforms to spec). My next statement is: there are stupid apps that rely on the particular order returned by RI (regardless of spec). I know one already. The question is: should we care or not? Can you figure out what their order is? If so, I'd use that since we are free to do what we want, and if someone does depende on this, it's one less change, and it's spec compliant. As well as I know, the order is what the methods are declared in java source. (Cannot find any document currently ;-) ) IIRC, Sun and JRockit behave differently to this matter, JRockit's VM reports methods in reversed order. Besides, there are 2 APIs: getDeclaredMethods() and getMethods() - we should consider both if we really care. And detecting right order for the last is tedious - taking into account variety of heritable methods (declared directly, inherited from superclass(es), inherited from superinterface(s), inherited from superinterfaces of superclasses). I agree with this assertion. The implementation of kernel classes for DRLVM was clean room one. (I believe Alexey used it to test. *Or J9 nevertheless*? IMHO it needs to specify when same discussions start). We've knew nothing about the algorithms used by RI. All we knew is our implementation should correspond to the specifications and not break them. The case discussed here is such one in my opinion. Could you please give prove why the compatibility needs here? What RI should be used for this purpose if any? Thanks, Vladimir. I believe we need a bit stronger motivation for scratching this issue, than a blunt testcase - some real-world application. -- Regards, Alexey Varlamov Best regards, Richard Geir 2006/7/13, Geir Magnusson Jr [EMAIL PROTECTED]: I assume you mean [drlvm], since java.lang.Class in [classlib] is just a stub, right? Anyway, what would you say exactly? That our not in any particular order is different than the not in any particular order that the RI does? I'm not trying to make light of it, but it sounds like all is correct. geir Alexei Zakharov wrote: Hi, I have discovered we have small incompatibility in our java.lang.Class implementation. The order of elements returned by Class.getDeclaredMethods() differs from RI. The spec says here: The elements in the array returned are not sorted and are not in any particular order. But I already know one application that relies on this - this was one of java.beans test (already patched). I don't want to say this is somehow bad but still like to inform the community about this issue. Probably we need to rise non-bug differences JIRA? Thanks, -- Alexei Zakharov, Intel Middleware Product Division - 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]
