commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Schneeberger (JIRA)" <>
Subject [jira] [Updated] (BEANUTILS-340) Property with getter from generic interface returns wrong readMethod/propertyType on Linux environment
Date Thu, 09 Jun 2011 14:01:59 GMT


Travis Schneeberger updated BEANUTILS-340:

    Attachment: jira_340.patch

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

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:
>             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
> 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:

View raw message