[ 
https://issues.apache.org/jira/browse/BEANUTILS-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048657#comment-13048657
 ] 

Travis Schneeberger commented on BEANUTILS-340:
-----------------------------------------------

If anyone would like a patched version of commons-beanutils there is one 
located @

http://nexus.kuali.org/content/groups/public/org/kuali/commons/commons-beanutils/1.8.3-kuali-SNAPSHOT/

This jar contains my patch that I've attached to this jira and is based off the 
1.8.3 release. Note that the maven coordinates of this artifact are 
"org.kuali.commons:commons-beanutils:1.8.3-kuali-SNAPSHOT"   This is currently 
a SNAPSHOT version but will be a final release in a few months if this jira 
isn't addressed before then.  Enjoy!

> Property with getter from generic interface returns wrong 
> readMethod/propertyType on Linux environment
> ------------------------------------------------------------------------------------------------------
>
>                 Key: BEANUTILS-340
>                 URL: https://issues.apache.org/jira/browse/BEANUTILS-340
>             Project: Commons BeanUtils
>          Issue Type: Bug
>          Components: Bean / Property Utils
>    Affects Versions: 1.8.0-BETA
>         Environment: ==Works correctly in==
> Windows XP
> java version "1.5.0_12"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
> Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode)
> ==Fails in==
> Linux 2.6.27-gentoo-r8 #6 SMP Thu Feb 5 19:18:16 MST 2009 i686 06/17 
> GenuineIntel GNU/Linux
> java version "1.5.0_17"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_17-b04)
> Java HotSpot(TM) Server VM (build 1.5.0_17-b04, mixed mode)
>            Reporter: Dave Lindquist
>            Priority: Minor
>             Fix For: LATER THAN 1.8.4
>
>         Attachments: jira_340.patch, jira_340_new.patch
>
>
> PropertyUtils.getPropertyDescriptors is returning the wrong readMethod (and 
> thus the wrong property type) when a method is implemented from a genericized 
> interface, but only on some environments.  This seems to work on Windows, but 
> fails on Linux.  (Compile environment does not matter, runtime environment 
> does seem to matter.)
> Take the following test class:
> {code}
> public class Testing
> {
>       public static void main(String[] args) throws Exception
>       {
>               for(PropertyDescriptor desc : 
> PropertyUtils.getPropertyDescriptors(Test2.class))
>               {
>                       if(desc.getName().equals("something"))
>                       {
>                               System.out.println(desc.getName() + "\t" + 
> desc.getPropertyType() + "\t" + desc.getReadMethod() + "\t" + 
> desc.getReadMethod().isSynthetic() + "\t" + desc.getReadMethod().isBridge());
>                       }
>               }
>       }
>       
>       // An interface with generics, and with getter and setter defined 
> 'generically'.
>       public static interface Test<T extends Number>
>       {
>               public T getSomething();
>               
>               public void setSomething(T something);
>       }
>       
>       // A concrete class using a specific genericization of the interface 
> (Long), with getter and setter implemented appropriately.
>       public static class Test2 implements Test<Long>
>       {
>               public Long getSomething()
>               {
>                       return(null);
>               }
>               
>               public void setSomething(Long something)
>               {
>                       
>               }
>       }
> }
> {code}
> When run on Windows XP, and working correctly, this prints:
>     something class java.lang.Long    public java.lang.Long 
> Testing$Test2.getSomething()      false   false
> indicating that it got the 'long' version of the method, and that this method 
> is NOT synthetic or a bridge method.
> However, when run on Linux, this prints:
> something     class java.lang.Number  public volatile java.lang.Number 
> Testing$Test2.getSomething()   true    true
> which is the signature from the interface, and is marked with both synthetic 
> and bridge, indicating that this is not the 'real' method, but the 
> compiler-created method due to generics.
> I think that it should be ignoring the 'synthetic/bridge' method auto-created 
> by the compiler, but I'm not sure why it is environment-dependent.  Perhaps 
> the environment somehow controls the method definition order?  (At runtime, 
> not compile time, obviously.)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to