Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Message-ID: <880844691.5611270814870867.JavaMail.jira@brutus.apache.org>
Date: Fri, 9 Apr 2010 12:07:50 +0000 (UTC)
From: "Oliver Deakin (JIRA)" <jira@apache.org>
To: commits@harmony.apache.org
Subject: [jira] Resolved: (HARMONY-4392)
 [classlib][beans]java.beans.Statement/Expression cannot handle overloaded
 constructor properly
In-Reply-To: <28813431.1183968725684.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ 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.