[
https://issues.apache.org/jira/browse/BEANUTILS-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046548#comment-13046548
]
Travis Schneeberger edited comment on BEANUTILS-340 at 6/13/11 5:07 PM:
------------------------------------------------------------------------
I've included a patch file which works around the java.bean.Introspector bug.
Please consider incorporating this patch in your next release. Here are a few
details:
I searched for all the places commons-beanutils interfaces with the
Introspector api to retrieve PropertyDescriptors. Then I checked each read &
write method to see if it was synthetic or bridge and if it is I attempt to
replace it with the non synthetic/bridge version.
This patch is java 1.3 compatible since I'm using reflection to check if a
method is synthetic or bridge.
I've also included a unit test. I've had to comment out the test case since it
relies on java 1.5+ features.
This patch was generated against the 1.8.3 release. Please let me know if there
is anything else I can do to help this get included in the next release of
beanutils.
was (Author: leo.herbie):
I've included a patch file which works around the java.bean.Introspector
bug. Please consider incorporating this patch in your next release. Here are
a few details:
I searched for all the places commons-beanutils interfaces with the
Introspector api to retrieve PropertyDescriptors. Then I checked each read &
write method to see if it was synthetic or bridge and if it is I attempt to
replace it with the non synthetic/bridge version.
Note: doing it on the write method may not be necessary since covariant returns
doesn't affect it but I did it anyway b/c I'm not familiar with all the places
java uses synthetic/bridge methods
This patch is java 1.3 compatible since I'm using reflection to check if a
method is synthetic or bridge.
I've also included a unit test. I've had to comment out the test case since it
relies on java 1.5+ features.
This patch was generated against the 1.8.3 release. Please let me know if there
is anything else I can do to help this get included in the next release of
beanutils.
> 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
