I'm fine with marking it as a non-bug difference, with the option to fix
it if we find some compelling application that relies on this non-spec
behavior. Is that weasely enough?
Regards,
Tim
Alexei Zakharov wrote:
> Hi Tim,
>
> <-- persuasion starts here
>
> Let me cite the spec describing design patterns for properties,
> JavaBeans spec v1.01-A (Aug 8, 1997), page 55:
>
> ---
> 8.3 Design Patterns for Properties
>
> 8.3.1 Simple properties
> By default, we use design patterns to locate properties by looking for
> methods of the form:
>
> public <PropertyType> get<PropertyName>();
> public void set<PropertyName>(<PropertyType> a);
>
> 8.3.2 Boolean properties
> In addition, for boolean properties, we allow a
>
> public boolean is<PropertyName>();
>
> 8.3.3 Indexed properties
> If we find a property whose type is an array "<PropertyElement>[]",
> then we also look for methods of the form:
>
> public <PropertyElement> get<PropertyName>(int a);
> public void set<PropertyName>(int a, <PropertyElement> b);
> ---
>
> So we have only three design patterns specified for properties. That's
> all. I didn't found any mentioning about any extra design patterns and
> I've never heard anything about setDefaults() or smth. like it.
>
> On the other hand, if I understand things correctly the Introspector
> class should be the decision-making center for such type of things.
> I.e. if Introspector says there is no properties then there should be
> no properties. RI doesn't seem to be using Introspector in the example
> I've described ealier. Thus I still think it looks like RI bug.
>
> <-- end of persuasion
>
> Thanks and regards,
>
> 2006/10/14, Tim Ellison <[EMAIL PROTECTED]>:
>> That is strange behavior, since as you point out it does not set a
>> parametrized value, however, I wonder if there is some assumption that
>> the setFoo() method may be a mutator anyway, e.g. setDefaults() or
>> something like that? Just guessing.
>>
>> In this case it may be safer to follow the RI -- but I'm open to
>> persuasion.
>>
>> Regards,
>> Tim
>>
>> Alexei Zakharov wrote:
>> > Hi all,
>> >
>> > Let me disturb you with another boring "RI inconsistency in beans"
>> > –type of message. :) It seems I found a bug in RI. In
>> > java.beans.EventHandler. I think RI incorrectly determines properties
>> > here. According to spec, common sense and even the RI's implementation
>> > of java.beans.Introspector the following bean should not contain any
>> > properties:
>> >
>> > public static class MyBean {
>> > public void setProp1() {}
>> > }
>> >
>> > because "setProp1()" is not a valid setter method – it does not
>> > contain a new value to set.
>> > However, the following test fails on RI:
>> >
>> > <---
>> > import java.beans.*;
>> >
>> > public class TestBeanInfo1 {
>> > public static class MyBean {
>> > public void setProp1() {}
>> > }
>> >
>> > public static void main(String argv[]) throws Exception {
>> > MyBean bean = new MyBean();
>> > // "prop1" is neither the name of writeable property nor the
>> > name of any public method
>> > Object proxy = EventHandler.create(
>> > PropertyChangeListener.class, bean, "prop1");
>> >
>> > // just to show that Introspector doesn't see the property
>> > with name "prop1"
>> > PropertyDescriptor[] pds =
>> Introspector.getBeanInfo(MyBean.class,
>> > Introspector.USE_ALL_BEANINFO).getPropertyDescriptors();
>> > for (int i = 0; i < pds.length; i++) {
>> > System.out.println("Property found: " + pds[i].getName());
>> > }
>> >
>> > // should throw exception
>> > try {
>> > ((PropertyChangeListener) proxy).propertyChange(
>> > new PropertyChangeEvent(bean, "prop1", "1", "2"));
>> > System.out.println("FAIL");
>> > } catch (Throwable t) {
>> > System.out.println("PASS");
>> > }
>> > }
>> > }
>> > <---
>> >
>> > So it determines "prop1" as a valid property. IMHO this behavior is
>> > inconsistent and we should not follow RI. But I like to hear opinions
>> > from the rest of the community.
>> >
>> > Thanks,
>
>
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
