commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Lindquist (JIRA)" <j...@apache.org>
Subject [jira] Created: (BEANUTILS-340) Property with getter from generic interface returns wrong readMethod/propertyType on Linux environment
Date Tue, 03 Mar 2009 02:54:56 GMT
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


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.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message