Re: [classlib][beans] RI inconsistency in EventHandler
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 getPropertyName();
public void setPropertyName(PropertyType a);
8.3.2 Boolean properties
In addition, for boolean properties, we allow a
public boolean isPropertyName();
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 getPropertyName(int a);
public void setPropertyName(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,
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division, Russia
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][beans] RI inconsistency in EventHandler
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 getPropertyName();
public void setPropertyName(PropertyType a);
8.3.2 Boolean properties
In addition, for boolean properties, we allow a
public boolean isPropertyName();
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 getPropertyName(int a);
public void setPropertyName(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]
Re: [classlib][beans] RI inconsistency in EventHandler
I am ok with this. :) Will file a JIRA soon.
Regards,
2006/10/16, Tim Ellison [EMAIL PROTECTED]:
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 getPropertyName();
public void setPropertyName(PropertyType a);
8.3.2 Boolean properties
In addition, for boolean properties, we allow a
public boolean isPropertyName();
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 getPropertyName(int a);
public void setPropertyName(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,
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division, Russia
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][beans] RI inconsistency in EventHandler
HARMONY-1884 was created.
Thanks,
2006/10/16, Alexei Zakharov [EMAIL PROTECTED]:
I am ok with this. :) Will file a JIRA soon.
Regards,
2006/10/16, Tim Ellison [EMAIL PROTECTED]:
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 getPropertyName();
public void setPropertyName(PropertyType a);
8.3.2 Boolean properties
In addition, for boolean properties, we allow a
public boolean isPropertyName();
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 getPropertyName(int a);
public void setPropertyName(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,
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division, Russia
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division, Russia
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][beans] RI inconsistency in EventHandler
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]
