JDK-4168833 : Introspector creates indexed property descriptor from non-indexed property
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.beans
  • Affected Version: 1.1.6
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_nt
  • CPU: x86
  • Submitted: 1998-08-25
  • Updated: 2001-07-12
  • Resolved: 2001-07-12
Related Reports
Duplicate :  
Relates :  
Description

Name: chT40241			Date: 08/25/98


/**
 * This sample program demonstrates a bug in the 
 * java.beans.Introspector.
 * The bug is that the Introspector creates an indexed property 
 * from the IntrospectorTestSubClass below.  The get/set 
 * methods for the property are those of a non-indexed 
 * property.  The Introspector should create either a 
 * non-indexed property or create both an indexed and
 * non-indexed property.
 * 
 * This can be worked around by providing additional BeanInfo
 * for the class.
 * However, that is cumbersome for a large class library.
 *
 * Output from program:
 * <PRE>
 *    Descriptor: java.beans.IndexedPropertyDescriptor@1ec96f
 *    Read method: public java.lang.Object
 *            com.sastest.beans.IntrospectorTestSubClass.getFoo()
 *    Write method: public void 
 *            com.sastest.beans.IntrospectorTestSubClass.setFoo
 *                                             (java.lang.Object)
 * </PRE>
*/
package com.sastest.beans;

import java.beans.BeanInfo;
import java.beans.Introspector;
import java.beans.PropertyDescriptor;

public class IntrospectorTest {
   public static void main( String[] args ) {
      try {
         BeanInfo beanInfo =
                   Introspector.getBeanInfo(  
                                IntrospectorTestSubClass.class );
         PropertyDescriptor[] descriptors = 
                               beanInfo.getPropertyDescriptors();
         for ( int i = 0; i < descriptors.length; i++ ) {
            if ( descriptors[i].getName().equals( "foo" ) ) {
               System.out.println( "Descriptor: " +
                                    descriptors[i] );
               System.out.println( "Read method: " +
                                descriptors[i].getReadMethod() );
               System.out.println( "Write method: " +
                               descriptors[i].getWriteMethod() );
               } // if
          } // for
      }
      catch (Exception e) {
         System.out.println( "Exception: " + e );
      }
   }
}

/**
 * This class approximates java.awt.TextField with the "foo"
 * property standing in for "preferredSize".
 */
class IntrospectorTestBaseClass {
   private Object foo;
   public Object getFoo() {
      return foo;
   }
   public Object getFoo( int bar ) {
      return new Integer(bar);
   }
}

/**
 * This class approximates our subclass of java.awt.TextField 
 * with the "foo" property standing in for "preferredSize".
 */
class IntrospectorTestSubClass extends IntrospectorTestBaseClass {
   private Object foo;
   public void setFoo( Object foo ) {
      this.foo = foo;
   }
}

======================================================================

Comments
PUBLIC COMMENTS .
10-06-2004

EVALUATION In situations where a bean has inconsistent property accessor methods it is undefined which accessors the introspector will chose. In the example given, chosing an indexed accessor is as reasonable as any other choice. For any given property name, a given bean can only have a single property. It is not possible for a bean to have "different" properties with the same name. So the option of supporting both an indexed and a non-indexed property with the same name doesn't exist. In situations with ambiguous accessior methods, the right answer very definitely ***is*** to provide BeanInfo to specify the exact property behavior that is desired. However, in general, it is very desirabke to avoid introducing such ambuguities, as they will confuse users of the bean. I am closing this as "not a bug". graham.hamilton@Eng 1998-08-30 OK, after some more email: The problem is that the result property descriptor contains an inconsistent set of methods. It includes an indexed getter that returns an Object and a non-indexed getter that also returns an Object. I have created a slightly different test case where the indexed getter returns a font and the non-indexed getter returns a Color. This also shows the bug. We get an IndexedPropertyDescriptor that contains a incompatible set of properties. It looks like the fix requries adding some more careful checks in Introspector.addProperty to check for this case. Unfortunately that is fairly tricky code. I'm labelling this as a P4. We will fix it in a maintenance release after 1.2.0. graham.hamilton@Eng 1998-09-18 This will be a very tricky fix by adding another special case within addProperty. The crux of the problem is that the only the public declared methods for that class is put into the method cache. When the next iteration of the superclass is introspected, the logic in the addProperty method will not associate the correct getter/setter pairs. It seems like a pre-process step should be done to get the set of all the public methods from the start class to the stop class and then pick out PropertyDescriptors based on the return types of the public getters (find a matching setter). Then IndexedPropertyDescriptors should be extracted from the set. Seems like a lot of work to get this right but it could be worth it if the complexity of the addProperty() method is reduced. mark.davidson@Eng 2000-06-29 As part of the commited bug consolidation I'm going to be closing this as a dupe of 4387842. The essence of the bug is still explained in 4477877 but I'm keeping the faux IndexPropertyDescriptor bug open so that I can track the issue. mark.davidson@Eng 2001-07-11
11-07-2001