harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Deakin <oliver.dea...@googlemail.com>
Subject Re: Fwd: [jira] Updated: (HARMONY-4392) [classlib][beans]java.beans.Statement/Expression cannot handle overloaded constructor properly
Date Fri, 09 Apr 2010 13:54:36 GMT
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)<jira@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


Mime
View raw message