This discussion is archived
11 Replies Latest reply: Aug 20, 2010 5:32 PM by EJP RSS

Is this an Introspector bug?

843798 Newbie
Currently Being Moderated
class SumBean  {

    private int   carryAsCredit = 0;

    public final int getCarryAsCredit ()  {   return this.carryAsCredit ;   }
    
    public final void setCarryAsCredit ( final int b )  {  
        this.carryAsCredit = b;  }
    
    public final boolean isCarriedAsCredit() { return getCarryAsCredit () > 0; }
}
        BeanInfo beanInfo = Introspector.getBeanInfo( SumBean.class );
        PropertyDescriptor[] descriptors = beanInfo.getPropertyDescriptors();
         if( des.getWriteMethod()==null )  // it's null
When I comment out the boolean getter, it finds a write method. Order of method declaration is irrelevant. Another property acts the same way.

What the heck is going on here?
  • 1. Re: Is this an Introspector bug?
    843798 Newbie
    Currently Being Moderated
    Okay, here's another one.

    In a class in which no properties are bound, the Introspector reports that they are not bound.

    In a class in which some properties are bound, the Introspector reports that all properties are bound.

    I understand "bound" to mean, "emits a PropertyChangeEvent".

    Edit:
    I see that the class hierarchy holds references to PropertyChangeSupport and VetoableChangeSupport. I guess since there's no way for the Introspector to tell which properties use it, they have to assume that they all do. Is there a way to make only some properties bound?

    Edited by: DMF. on Aug 14, 2010 7:48 PM
  • 2. Re: Is this an Introspector bug?
    843798 Newbie
    Currently Being Moderated
    More on the OP: I've now found this in other classes and with different propertyTypes. In no case was the 'property' part of the boolean method name spelled the same as the field name, while those of the getter/setter pair were.
    .
  • 3. Re: Is this an Introspector bug?
    EJP Guru
    Currently Being Moderated
    The getter argument type has to agree with the getter return type for the pair to be considered as a property.
  • 4. Re: Is this an Introspector bug?
    843798 Newbie
    Currently Being Moderated
    ejp wrote:
    The getter argument type has to agree with the getter return type for the pair to be considered as a property.
    You mean the setter argument type? They do, and with the field type. Not only is the boolean spelled differently, it returns the wrong type. Perhaps the names are within a fuzzy match (though I've seen no statement that xetFieldname doesn't have to match exactly), but who knows - perhaps the names are confusing it.

    What makes me think it's a bug is that it finds the getter okay, but loses the setter, which isn't even close in format.


    Where would I look to find open defect reports?
  • 5. Re: Is this an Introspector bug?
    EJP Guru
    Currently Being Moderated
    Sorry, misread it completely.

    (a) Your SumBean works correctly for me: int carryAsCredit has a writer and boolean carriedAsCredit doesn't. Are you sure you're running the current object code?
    (b) Bound and Vetoable are off by default. You put them on by defining a companion BeanInfo class, in this case SumBeanBeanInfo extends BeanInfo.

    EJP
  • 6. Re: Is this an Introspector bug?
    843798 Newbie
    Currently Being Moderated
    You're still missing it. There is no carriedAsCredit property. boolean isCarriedAsCredit() is merely a convenience method to allow interpretation of the int carryAsCredit content to remain within the bean.

    Compiler and runtime are both from JDK 1.6.0_18 (x64). Not the latest, but late enough.


    Btw, this only occurs if Introspector is left to find accessors on its own. When the properties are defined in a BeanInfo class, there's no issue. Which is not inconsistent with a bug.


    You're right. When you run the Introspector (without BeanInfo) on the code in the OP it doesn't fail. But add a second property and it does. Try this:
    public class SumBean {
            
            private int   carryAsCredit = 0;
         
            public final int getCarryAsCredit ()  {   return this.carryAsCredit ;   }
            
            public final void setCarryAsCredit ( final int b )  {  
                this.carryAsCredit = b;  }
            
            public final boolean isCarriedAsCredit() { return getCarryAsCredit () > 0; }
    
            private int   carryAsDebit = 0;
            
            public final int getCarryAsDebit ()  {   return this.carryAsDebit ;   }
            
            public final void setCarryAsDebit ( final int b )  {  
                this.carryAsDebit = b;  }
      
    // will cause the second setter to get lost if uncommented      
    //        public final boolean isCarriedAsDebit() { return getCarryAsDebit () > 0; }
            
    }
  • 7. Re: Is this an Introspector bug?
    EJP Guru
    Currently Being Moderated
    I'm not missing it. From the point of view of the Introspector, carriedAsCredit is a read-only Boolean property, and carryAsCredit is a read-write int property. It works for me in the current JDK.
  • 8. Re: Is this an Introspector bug?
    843798 Newbie
    Currently Being Moderated
    Okay, I see your point. I've always used 'property' to mean a field and its accessor(s). If the Introspector is looking just at methods, then it's quite proper to have fieldless properties.

    In the meantime I made some changes to my reporting code and now I'm seeing exactly what you describe: three properties (or four with the last line uncommented), one (or two) of which have no write accessor. This is causing me to doubt my sanity! I stared at this "bug" for a day and a half before posting - it's hard to believe I misread the printout. But neither can I see what I might have changed that would have given me the wrong output. For one thing, when I ran it with one field and three methods (the original example), I could swear that I saw only one property reported.


    Unless I stumble across it again, I hereby declare this "bug" to be dead. Thanks for your help.
  • 9. Re: Is this an Introspector bug?
    843798 Newbie
    Currently Being Moderated
    Setting back to Unanswered.

    This may indeed be considered a bug in the Introspector, though it is caused by a user irregularity. I'll explain in the next post.
  • 10. Re: Is this an Introspector bug?
    843798 Newbie
    Currently Being Moderated
        public boolean isDoThisFirst  ()  {  
        
        public AClass getDoThisFirst ()  {
    
        public void setDoThisFirst ( final AClass b )  throws PropertyVetoException  {
    To the Introspector this is essentially declaring two properties with the same name but different types.

    With no BeanInfo class, the Introspector reports property boolean doThisFirst with no write method. All three methods are listed in the MethodDescriptors.

    With a BeanInfo class, the Introspector reports property AClass doThisFirst with no write method.

    To my mind, it should throw an exception, or at least report an error as it does "method not found". Instead it gives no clue that there's something wrong.

    I think this is worth a bug report, even if they choose not to fix it. Is there someplace to file one?
  • 11. Re: Is this an Introspector bug?
    EJP Guru
    Currently Being Moderated
    That's a new problem. The first one was just your expectation that the Introspector looks at fields when the Bean Specification says that bean properties are determined by methods.

    I'm not clear about this one. In the presence of a BeanInfo class the Introspector will do whatever the BeanInfo class tells it to do. What is it telling it to do?

    Re bug reports: the [Bug Database|http://bugs.sun.com].