Uploaded image for project: 'Commons BeanUtils'
  1. Commons BeanUtils
  2. BEANUTILS-340

Property with getter from generic interface returns wrong readMethod/propertyType on Linux environment

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Open
    • Minor
    • Resolution: Unresolved
    • 1.8.0-BETA
    • 2.0.0
    • Bean / Property Utils
    • None

    Description

      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:

      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)
      		{
      			
      		}
      	}
      }
      

      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.)

      Attachments

        1. jira_340.patch
          13 kB
          Travis Schneeberger
        2. jira_340_new.patch
          23 kB
          Travis Schneeberger

        Issue Links

          Activity

            People

              Unassigned Unassigned
              dlindquist Dave Lindquist
              Votes:
              2 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated: