You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Paulex Yang (JIRA)" <ji...@apache.org> on 2007/07/09 10:12:05 UTC
[jira] Created: (HARMONY-4392)
[classlib][beans]java.beans.Statement/Expression cannot handle overloaded
constructor properly
[classlib][beans]java.beans.Statement/Expression cannot handle overloaded constructor properly
----------------------------------------------------------------------------------------------
Key: HARMONY-4392
URL: https://issues.apache.org/jira/browse/HARMONY-4392
Project: Harmony
Issue Type: Bug
Components: Non-bug differences from RI
Reporter: Paulex Yang
Consider test case below[1], which is extracted from o.a.h.beans.tests.java.beans.ExpressionTest. Seems RI 5 and 6 return different results, further, both results depend on the constructors' order in MockObject and follow a mysterious rules, while in spec, it is required to "choose the most specific method using the algorithm specified in the Java Language Specification". More interesting stuffs is, if you construct a Statement, Expression's superclass, in same way, RI 5 has different result, although in spec, the only difference between the 2 classes are Expression adds a value property.
My guess on RI's behavior is it tries to list all constructors via reflection and then check them one by one whether all parameter is assignable, at last returns the first matching result, so the result actually depends on VM's reflection implementation. Current Harmony's beans actually works in similar way, but unfortunately the different VMs just return constructors in different ways, including different version of RI.
So the issue now is if we need to fix it as spec or let it be in "random" behavior as RI? I prefer to fix Harmony to follow spec.
[1]
public ExpressionTest extends TestCase{
public void testGetValue_UnboundedOverloadedConstructors() throws Exception {
arguments = new Object[] { "test" };
t = new Expression(MockObject.class, "new", arguments);
assertTrue(t.getValue() instanceof MockObject);
MockObject.assertCalled("new3", arguments);
arguments = new Object[] { new Integer(1) };
t = new Expression(MockObject.class, "new", arguments);
assertTrue(t.getValue() instanceof MockObject);
MockObject.assertCalled("new1-2", arguments);
}
public static class MockObject{
public MockObject(String o) {
reset();
calledMethod = "new3";
receivedArguments.add(o);
}
public MockObject(Object o) {
reset();
calledMethod = "new2";
receivedArguments.add(o);
}
public MockObject(Integer o) {
reset();
calledMethod = "new1-2";
receivedArguments.add(o);
}
public static void assertCalled(String methodName, Object[] arguments) {
assertEquals(methodName, calledMethod);
assertTrue(Arrays.equals(arguments, receivedArguments.toArray()));
reset();
}
public static void reset() {
receivedArguments.clear();
calledMethod = null;
}
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Fwd: [jira] Updated: (HARMONY-4392) [classlib][beans]java.beans.Statement/Expression
cannot handle overloaded constructor properly
Posted by Oliver Deakin <ol...@googlemail.com>.
Thanks Kevin - patch applied at r932371.
Regards,
Oliver
On 09/04/2010 08:21, Kevin Zhou wrote:
> Hi,
>
> I made a patch for HARMONY-4392 which was previously raised by Paulex Yang.
> For the background information, please refer to [1]. Is there someone who
> can help to review this patch and test it?
>
> [1] https://issues.apache.org/jira/browse/HARMONY-4392
>
> Thank
> Kevin Zhou
>
> ---------- Forwarded message ----------
> From: Kevin Zhou (JIRA)<ji...@apache.org>
> Date: Fri, Apr 9, 2010 at 3:15 PM
> Subject: [jira] Updated: (HARMONY-4392)
> [classlib][beans]java.beans.Statement/Expression cannot handle overloaded
> constructor properly
> To: commits@harmony.apache.org
>
>
>
> [
> https://issues.apache.org/jira/browse/HARMONY-4392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>
> Kevin Zhou updated HARMONY-4392:
> --------------------------------
>
> Attachment: HARMONY-4392.diff
>
> Would you please help to review this?
>
>
>> [classlib][beans]java.beans.Statement/Expression cannot handle overloaded
>>
> constructor properly
>
>>
> ----------------------------------------------------------------------------------------------
>
>> Key: HARMONY-4392
>> URL: https://issues.apache.org/jira/browse/HARMONY-4392
>> Project: Harmony
>> Issue Type: Bug
>> Components: Non-bug differences from RI
>> Reporter: Paulex Yang
>> Attachments: HARMONY-4392.diff
>>
>>
>> Consider test case below[1], which is extracted from
>>
> o.a.h.beans.tests.java.beans.ExpressionTest. Seems RI 5 and 6 return
> different results, further, both results depend on the constructors' order
> in MockObject and follow a mysterious rules, while in spec, it is required
> to "choose the most specific method using the algorithm specified in the
> Java Language Specification". More interesting stuffs is, if you construct
> a Statement, Expression's superclass, in same way, RI 5 has different
> result, although in spec, the only difference between the 2 classes are
> Expression adds a value property.
>
>> My guess on RI's behavior is it tries to list all constructors via
>>
> reflection and then check them one by one whether all parameter is
> assignable, at last returns the first matching result, so the result
> actually depends on VM's reflection implementation. Current Harmony's beans
> actually works in similar way, but unfortunately the different VMs just
> return constructors in different ways, including different version of RI.
>
>> So the issue now is if we need to fix it as spec or let it be in "random"
>>
> behavior as RI? I prefer to fix Harmony to follow spec.
>
>> [1]
>> public ExpressionTest extends TestCase{
>> public void testGetValue_UnboundedOverloadedConstructors() throws
>>
> Exception {
>
>> arguments = new Object[] { "test" };
>> t = new Expression(MockObject.class, "new", arguments);
>> assertTrue(t.getValue() instanceof MockObject);
>> MockObject.assertCalled("new3", arguments);
>> arguments = new Object[] { new Integer(1) };
>> t = new Expression(MockObject.class, "new", arguments);
>> assertTrue(t.getValue() instanceof MockObject);
>> MockObject.assertCalled("new1-2", arguments);
>> }
>> public static class MockObject{
>> public MockObject(String o) {
>> reset();
>> calledMethod = "new3";
>> receivedArguments.add(o);
>> }
>> public MockObject(Object o) {
>> reset();
>> calledMethod = "new2";
>> receivedArguments.add(o);
>> }
>>
>> public MockObject(Integer o) {
>> reset();
>> calledMethod = "new1-2";
>> receivedArguments.add(o);
>> }
>> public static void assertCalled(String methodName, Object[]
>>
> arguments) {
>
>> assertEquals(methodName, calledMethod);
>> assertTrue(Arrays.equals(arguments,
>>
> receivedArguments.toArray()));
>
>> reset();
>> }
>> public static void reset() {
>> receivedArguments.clear();
>> calledMethod = null;
>> }
>> }
>> }
>>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
>
>
>
--
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Fwd: [jira] Updated: (HARMONY-4392) [classlib][beans]java.beans.Statement/Expression
cannot handle overloaded constructor properly
Posted by Kevin Zhou <zh...@gmail.com>.
Hi,
I made a patch for HARMONY-4392 which was previously raised by Paulex Yang.
For the background information, please refer to [1]. Is there someone who
can help to review this patch and test it?
[1] https://issues.apache.org/jira/browse/HARMONY-4392
Thank
Kevin Zhou
---------- Forwarded message ----------
From: Kevin Zhou (JIRA) <ji...@apache.org>
Date: Fri, Apr 9, 2010 at 3:15 PM
Subject: [jira] Updated: (HARMONY-4392)
[classlib][beans]java.beans.Statement/Expression cannot handle overloaded
constructor properly
To: commits@harmony.apache.org
[
https://issues.apache.org/jira/browse/HARMONY-4392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
Kevin Zhou updated HARMONY-4392:
--------------------------------
Attachment: HARMONY-4392.diff
Would you please help to review this?
> [classlib][beans]java.beans.Statement/Expression cannot handle overloaded
constructor properly
>
----------------------------------------------------------------------------------------------
>
> Key: HARMONY-4392
> URL: https://issues.apache.org/jira/browse/HARMONY-4392
> Project: Harmony
> Issue Type: Bug
> Components: Non-bug differences from RI
> Reporter: Paulex Yang
> Attachments: HARMONY-4392.diff
>
>
> Consider test case below[1], which is extracted from
o.a.h.beans.tests.java.beans.ExpressionTest. Seems RI 5 and 6 return
different results, further, both results depend on the constructors' order
in MockObject and follow a mysterious rules, while in spec, it is required
to "choose the most specific method using the algorithm specified in the
Java Language Specification". More interesting stuffs is, if you construct
a Statement, Expression's superclass, in same way, RI 5 has different
result, although in spec, the only difference between the 2 classes are
Expression adds a value property.
> My guess on RI's behavior is it tries to list all constructors via
reflection and then check them one by one whether all parameter is
assignable, at last returns the first matching result, so the result
actually depends on VM's reflection implementation. Current Harmony's beans
actually works in similar way, but unfortunately the different VMs just
return constructors in different ways, including different version of RI.
> So the issue now is if we need to fix it as spec or let it be in "random"
behavior as RI? I prefer to fix Harmony to follow spec.
> [1]
> public ExpressionTest extends TestCase{
> public void testGetValue_UnboundedOverloadedConstructors() throws
Exception {
> arguments = new Object[] { "test" };
> t = new Expression(MockObject.class, "new", arguments);
> assertTrue(t.getValue() instanceof MockObject);
> MockObject.assertCalled("new3", arguments);
> arguments = new Object[] { new Integer(1) };
> t = new Expression(MockObject.class, "new", arguments);
> assertTrue(t.getValue() instanceof MockObject);
> MockObject.assertCalled("new1-2", arguments);
> }
> public static class MockObject{
> public MockObject(String o) {
> reset();
> calledMethod = "new3";
> receivedArguments.add(o);
> }
> public MockObject(Object o) {
> reset();
> calledMethod = "new2";
> receivedArguments.add(o);
> }
>
> public MockObject(Integer o) {
> reset();
> calledMethod = "new1-2";
> receivedArguments.add(o);
> }
> public static void assertCalled(String methodName, Object[]
arguments) {
> assertEquals(methodName, calledMethod);
> assertTrue(Arrays.equals(arguments,
receivedArguments.toArray()));
> reset();
> }
> public static void reset() {
> receivedArguments.clear();
> calledMethod = null;
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
--
Best regards,
Yours, Kevin Zhou
[jira] Updated: (HARMONY-4392)
[classlib][beans]java.beans.Statement/Expression cannot handle overloaded
constructor properly
Posted by "Kevin Zhou (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kevin Zhou updated HARMONY-4392:
--------------------------------
Attachment: HARMONY-4392.diff
Would you please help to review this?
> [classlib][beans]java.beans.Statement/Expression cannot handle overloaded constructor properly
> ----------------------------------------------------------------------------------------------
>
> Key: HARMONY-4392
> URL: https://issues.apache.org/jira/browse/HARMONY-4392
> Project: Harmony
> Issue Type: Bug
> Components: Non-bug differences from RI
> Reporter: Paulex Yang
> Attachments: HARMONY-4392.diff
>
>
> Consider test case below[1], which is extracted from o.a.h.beans.tests.java.beans.ExpressionTest. Seems RI 5 and 6 return different results, further, both results depend on the constructors' order in MockObject and follow a mysterious rules, while in spec, it is required to "choose the most specific method using the algorithm specified in the Java Language Specification". More interesting stuffs is, if you construct a Statement, Expression's superclass, in same way, RI 5 has different result, although in spec, the only difference between the 2 classes are Expression adds a value property.
> My guess on RI's behavior is it tries to list all constructors via reflection and then check them one by one whether all parameter is assignable, at last returns the first matching result, so the result actually depends on VM's reflection implementation. Current Harmony's beans actually works in similar way, but unfortunately the different VMs just return constructors in different ways, including different version of RI.
> So the issue now is if we need to fix it as spec or let it be in "random" behavior as RI? I prefer to fix Harmony to follow spec.
> [1]
> public ExpressionTest extends TestCase{
> public void testGetValue_UnboundedOverloadedConstructors() throws Exception {
> arguments = new Object[] { "test" };
> t = new Expression(MockObject.class, "new", arguments);
> assertTrue(t.getValue() instanceof MockObject);
> MockObject.assertCalled("new3", arguments);
> arguments = new Object[] { new Integer(1) };
> t = new Expression(MockObject.class, "new", arguments);
> assertTrue(t.getValue() instanceof MockObject);
> MockObject.assertCalled("new1-2", arguments);
> }
> public static class MockObject{
> public MockObject(String o) {
> reset();
> calledMethod = "new3";
> receivedArguments.add(o);
> }
> public MockObject(Object o) {
> reset();
> calledMethod = "new2";
> receivedArguments.add(o);
> }
>
> public MockObject(Integer o) {
> reset();
> calledMethod = "new1-2";
> receivedArguments.add(o);
> }
> public static void assertCalled(String methodName, Object[] arguments) {
> assertEquals(methodName, calledMethod);
> assertTrue(Arrays.equals(arguments, receivedArguments.toArray()));
> reset();
> }
> public static void reset() {
> receivedArguments.clear();
> calledMethod = null;
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-4392)
[classlib][beans]java.beans.Statement/Expression cannot handle overloaded
constructor properly
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12855386#action_12855386 ]
Hudson commented on HARMONY-4392:
---------------------------------
Integrated in Harmony-1.5-head-linux-x86_64 #751 (See [http://hudson.zones.apache.org/hudson/job/Harmony-1.5-head-linux-x86_64/751/])
Apply patch for HARMONY-4392 ([classlib][beans]java.beans.Statement/Expression cannot handle overloaded constructor properly)
> [classlib][beans]java.beans.Statement/Expression cannot handle overloaded constructor properly
> ----------------------------------------------------------------------------------------------
>
> Key: HARMONY-4392
> URL: https://issues.apache.org/jira/browse/HARMONY-4392
> Project: Harmony
> Issue Type: Bug
> Components: Non-bug differences from RI
> Reporter: Paulex Yang
> Assignee: Oliver Deakin
> Fix For: 6.0M2, 5.0M14
>
> Attachments: HARMONY-4392.diff
>
>
> Consider test case below[1], which is extracted from o.a.h.beans.tests.java.beans.ExpressionTest. Seems RI 5 and 6 return different results, further, both results depend on the constructors' order in MockObject and follow a mysterious rules, while in spec, it is required to "choose the most specific method using the algorithm specified in the Java Language Specification". More interesting stuffs is, if you construct a Statement, Expression's superclass, in same way, RI 5 has different result, although in spec, the only difference between the 2 classes are Expression adds a value property.
> My guess on RI's behavior is it tries to list all constructors via reflection and then check them one by one whether all parameter is assignable, at last returns the first matching result, so the result actually depends on VM's reflection implementation. Current Harmony's beans actually works in similar way, but unfortunately the different VMs just return constructors in different ways, including different version of RI.
> So the issue now is if we need to fix it as spec or let it be in "random" behavior as RI? I prefer to fix Harmony to follow spec.
> [1]
> public ExpressionTest extends TestCase{
> public void testGetValue_UnboundedOverloadedConstructors() throws Exception {
> arguments = new Object[] { "test" };
> t = new Expression(MockObject.class, "new", arguments);
> assertTrue(t.getValue() instanceof MockObject);
> MockObject.assertCalled("new3", arguments);
> arguments = new Object[] { new Integer(1) };
> t = new Expression(MockObject.class, "new", arguments);
> assertTrue(t.getValue() instanceof MockObject);
> MockObject.assertCalled("new1-2", arguments);
> }
> public static class MockObject{
> public MockObject(String o) {
> reset();
> calledMethod = "new3";
> receivedArguments.add(o);
> }
> public MockObject(Object o) {
> reset();
> calledMethod = "new2";
> receivedArguments.add(o);
> }
>
> public MockObject(Integer o) {
> reset();
> calledMethod = "new1-2";
> receivedArguments.add(o);
> }
> public static void assertCalled(String methodName, Object[] arguments) {
> assertEquals(methodName, calledMethod);
> assertTrue(Arrays.equals(arguments, receivedArguments.toArray()));
> reset();
> }
> public static void reset() {
> receivedArguments.clear();
> calledMethod = null;
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (HARMONY-4392)
[classlib][beans]java.beans.Statement/Expression cannot handle overloaded
constructor properly
Posted by "Oliver Deakin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oliver Deakin resolved HARMONY-4392.
------------------------------------
Resolution: Fixed
Fix Version/s: 5.0M14
6.0M2
Patch applied at repo revision r932371 - please check it was applied as expected.
> [classlib][beans]java.beans.Statement/Expression cannot handle overloaded constructor properly
> ----------------------------------------------------------------------------------------------
>
> Key: HARMONY-4392
> URL: https://issues.apache.org/jira/browse/HARMONY-4392
> Project: Harmony
> Issue Type: Bug
> Components: Non-bug differences from RI
> Reporter: Paulex Yang
> Assignee: Oliver Deakin
> Fix For: 6.0M2, 5.0M14
>
> Attachments: HARMONY-4392.diff
>
>
> Consider test case below[1], which is extracted from o.a.h.beans.tests.java.beans.ExpressionTest. Seems RI 5 and 6 return different results, further, both results depend on the constructors' order in MockObject and follow a mysterious rules, while in spec, it is required to "choose the most specific method using the algorithm specified in the Java Language Specification". More interesting stuffs is, if you construct a Statement, Expression's superclass, in same way, RI 5 has different result, although in spec, the only difference between the 2 classes are Expression adds a value property.
> My guess on RI's behavior is it tries to list all constructors via reflection and then check them one by one whether all parameter is assignable, at last returns the first matching result, so the result actually depends on VM's reflection implementation. Current Harmony's beans actually works in similar way, but unfortunately the different VMs just return constructors in different ways, including different version of RI.
> So the issue now is if we need to fix it as spec or let it be in "random" behavior as RI? I prefer to fix Harmony to follow spec.
> [1]
> public ExpressionTest extends TestCase{
> public void testGetValue_UnboundedOverloadedConstructors() throws Exception {
> arguments = new Object[] { "test" };
> t = new Expression(MockObject.class, "new", arguments);
> assertTrue(t.getValue() instanceof MockObject);
> MockObject.assertCalled("new3", arguments);
> arguments = new Object[] { new Integer(1) };
> t = new Expression(MockObject.class, "new", arguments);
> assertTrue(t.getValue() instanceof MockObject);
> MockObject.assertCalled("new1-2", arguments);
> }
> public static class MockObject{
> public MockObject(String o) {
> reset();
> calledMethod = "new3";
> receivedArguments.add(o);
> }
> public MockObject(Object o) {
> reset();
> calledMethod = "new2";
> receivedArguments.add(o);
> }
>
> public MockObject(Integer o) {
> reset();
> calledMethod = "new1-2";
> receivedArguments.add(o);
> }
> public static void assertCalled(String methodName, Object[] arguments) {
> assertEquals(methodName, calledMethod);
> assertTrue(Arrays.equals(arguments, receivedArguments.toArray()));
> reset();
> }
> public static void reset() {
> receivedArguments.clear();
> calledMethod = null;
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (HARMONY-4392)
[classlib][beans]java.beans.Statement/Expression cannot handle overloaded
constructor properly
Posted by "Oliver Deakin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oliver Deakin reassigned HARMONY-4392:
--------------------------------------
Assignee: Oliver Deakin
> [classlib][beans]java.beans.Statement/Expression cannot handle overloaded constructor properly
> ----------------------------------------------------------------------------------------------
>
> Key: HARMONY-4392
> URL: https://issues.apache.org/jira/browse/HARMONY-4392
> Project: Harmony
> Issue Type: Bug
> Components: Non-bug differences from RI
> Reporter: Paulex Yang
> Assignee: Oliver Deakin
> Attachments: HARMONY-4392.diff
>
>
> Consider test case below[1], which is extracted from o.a.h.beans.tests.java.beans.ExpressionTest. Seems RI 5 and 6 return different results, further, both results depend on the constructors' order in MockObject and follow a mysterious rules, while in spec, it is required to "choose the most specific method using the algorithm specified in the Java Language Specification". More interesting stuffs is, if you construct a Statement, Expression's superclass, in same way, RI 5 has different result, although in spec, the only difference between the 2 classes are Expression adds a value property.
> My guess on RI's behavior is it tries to list all constructors via reflection and then check them one by one whether all parameter is assignable, at last returns the first matching result, so the result actually depends on VM's reflection implementation. Current Harmony's beans actually works in similar way, but unfortunately the different VMs just return constructors in different ways, including different version of RI.
> So the issue now is if we need to fix it as spec or let it be in "random" behavior as RI? I prefer to fix Harmony to follow spec.
> [1]
> public ExpressionTest extends TestCase{
> public void testGetValue_UnboundedOverloadedConstructors() throws Exception {
> arguments = new Object[] { "test" };
> t = new Expression(MockObject.class, "new", arguments);
> assertTrue(t.getValue() instanceof MockObject);
> MockObject.assertCalled("new3", arguments);
> arguments = new Object[] { new Integer(1) };
> t = new Expression(MockObject.class, "new", arguments);
> assertTrue(t.getValue() instanceof MockObject);
> MockObject.assertCalled("new1-2", arguments);
> }
> public static class MockObject{
> public MockObject(String o) {
> reset();
> calledMethod = "new3";
> receivedArguments.add(o);
> }
> public MockObject(Object o) {
> reset();
> calledMethod = "new2";
> receivedArguments.add(o);
> }
>
> public MockObject(Integer o) {
> reset();
> calledMethod = "new1-2";
> receivedArguments.add(o);
> }
> public static void assertCalled(String methodName, Object[] arguments) {
> assertEquals(methodName, calledMethod);
> assertTrue(Arrays.equals(arguments, receivedArguments.toArray()));
> reset();
> }
> public static void reset() {
> receivedArguments.clear();
> calledMethod = null;
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (HARMONY-4392)
[classlib][beans]java.beans.Statement/Expression cannot handle overloaded
constructor properly
Posted by "Kevin Zhou (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kevin Zhou closed HARMONY-4392.
-------------------------------
Estimated Complexity: Moderate (was: Unknown)
Verified, thanks
> [classlib][beans]java.beans.Statement/Expression cannot handle overloaded constructor properly
> ----------------------------------------------------------------------------------------------
>
> Key: HARMONY-4392
> URL: https://issues.apache.org/jira/browse/HARMONY-4392
> Project: Harmony
> Issue Type: Bug
> Components: Non-bug differences from RI
> Reporter: Paulex Yang
> Assignee: Oliver Deakin
> Fix For: 6.0M2, 5.0M14
>
> Attachments: HARMONY-4392.diff
>
>
> Consider test case below[1], which is extracted from o.a.h.beans.tests.java.beans.ExpressionTest. Seems RI 5 and 6 return different results, further, both results depend on the constructors' order in MockObject and follow a mysterious rules, while in spec, it is required to "choose the most specific method using the algorithm specified in the Java Language Specification". More interesting stuffs is, if you construct a Statement, Expression's superclass, in same way, RI 5 has different result, although in spec, the only difference between the 2 classes are Expression adds a value property.
> My guess on RI's behavior is it tries to list all constructors via reflection and then check them one by one whether all parameter is assignable, at last returns the first matching result, so the result actually depends on VM's reflection implementation. Current Harmony's beans actually works in similar way, but unfortunately the different VMs just return constructors in different ways, including different version of RI.
> So the issue now is if we need to fix it as spec or let it be in "random" behavior as RI? I prefer to fix Harmony to follow spec.
> [1]
> public ExpressionTest extends TestCase{
> public void testGetValue_UnboundedOverloadedConstructors() throws Exception {
> arguments = new Object[] { "test" };
> t = new Expression(MockObject.class, "new", arguments);
> assertTrue(t.getValue() instanceof MockObject);
> MockObject.assertCalled("new3", arguments);
> arguments = new Object[] { new Integer(1) };
> t = new Expression(MockObject.class, "new", arguments);
> assertTrue(t.getValue() instanceof MockObject);
> MockObject.assertCalled("new1-2", arguments);
> }
> public static class MockObject{
> public MockObject(String o) {
> reset();
> calledMethod = "new3";
> receivedArguments.add(o);
> }
> public MockObject(Object o) {
> reset();
> calledMethod = "new2";
> receivedArguments.add(o);
> }
>
> public MockObject(Integer o) {
> reset();
> calledMethod = "new1-2";
> receivedArguments.add(o);
> }
> public static void assertCalled(String methodName, Object[] arguments) {
> assertEquals(methodName, calledMethod);
> assertTrue(Arrays.equals(arguments, receivedArguments.toArray()));
> reset();
> }
> public static void reset() {
> receivedArguments.clear();
> calledMethod = null;
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.