-
1. Re: Generic properties on interface and impl class
aloubyansky Oct 29, 2007 10:52 AM (in response to aloubyansky)It seems like this issue actually affects a number of tests in xb project, not just the recently discovered.
-
2. Re: Generic properties on interface and impl class
alesj Oct 29, 2007 12:28 PM (in response to aloubyansky)This code already returns 4 methods:
Method[] methods = BeanInfoGenericInterfaceImpl.class.getDeclaredMethods(); methods = [ public void org.jboss.test.beaninfo.support.BeanInfoGenericInterfaceImpl.setProperty(java.lang.String), public volatile void org.jboss.test.beaninfo.support.BeanInfoGenericInterfaceImpl.setProperty(java.lang.Object), public volatile java.lang.Object org.jboss.test.beaninfo.support.BeanInfoGenericInterfaceImpl.getProperty(), public java.lang.String org.jboss.test.beaninfo.support.BeanInfoGenericInterfaceImpl.getProperty()]
Is method being volatile enough to not include it in our declared methods? -
3. Re: Generic properties on interface and impl class
aloubyansky Oct 29, 2007 12:46 PM (in response to aloubyansky)Yes, the methods are there. I would expect the property type to be java.lang.String, not java.lang.Object.
-
4. Re: Generic properties on interface and impl class
alesj Oct 29, 2007 12:52 PM (in response to aloubyansky)Sure, but you can see that those are volatile.
Where in the code you cannot do:public volatile String getSomething() { return ""; }
If I add volatile restriction to AbstractBeanInfoFactoryif (result.contains(minfos[j]) == false && minfos[j].isPublic() && minfos[j].isStatic() == false && minfos[j].isVolatile() == false) result.add(minfos[j]);
your test passes, and none of the previous is broken. -
5. Re: Generic properties on interface and impl class
alesj Oct 29, 2007 1:08 PM (in response to aloubyansky)Not excluding volatile also break covariant implementations:
public class BeanInfoDoubleCovariantImpl extends BeanInfoNumberCovariantImpl { public Double getProperty() { return null; } public void setProperty(Double value) { } } public class BeanInfoNumberCovariantImpl { public Number getProperty() { return null; } public void setProperty(Number value) { } }
Excluding volatile takes care of them too. :-) -
6. Re: Generic properties on interface and impl class
starksm64 Oct 29, 2007 1:24 PM (in response to aloubyansky)Where is the volatile attribute as it applies to methods defined? I can't find this in the http://java.sun.com/docs/books/jvms/second_edition/ClassFileFormat-Java5.pdf update, nor the updated JLS.
-
7. Re: Generic properties on interface and impl class
alesj Oct 29, 2007 1:29 PM (in response to aloubyansky)"scott.stark@jboss.org" wrote:
Where is the volatile attribute as it applies to methods defined? I can't find this in the http://java.sun.com/docs/books/jvms/second_edition/ClassFileFormat-Java5.pdf update, nor the updated JLS.
Dunno.
Was looking at the same thing for the same thing. :-) -
8. Re: Generic properties on interface and impl class
kabirkhan Oct 29, 2007 1:30 PM (in response to aloubyansky)"volatile" for methods actually means "bridge". It has the same numeric value, but a different meaning
ACC_BRIDGE 0x0040 A bridge method, generated by the
compiler. -
9. Re: Generic properties on interface and impl class
starksm64 Oct 29, 2007 1:40 PM (in response to aloubyansky)Ok, then yes, we should be filtering volatile methods out of the property accessor candidates.
-
10. Re: Generic properties on interface and impl class
wolfc Oct 30, 2007 7:18 AM (in response to aloubyansky)"scott.stark@jboss.org" wrote:
Where is the volatile attribute as it applies to methods defined? I can't find this in the http://java.sun.com/docs/books/jvms/second_edition/ClassFileFormat-Java5.pdf update, nor the updated JLS.
JLS third editition 15.12.4.5 in the discussion footnote.
We should not have a isVolatile on MethodInfo, but isBridge. In theory it can change in the future. -
11. Re: Generic properties on interface and impl class
alesj Oct 30, 2007 3:03 PM (in response to aloubyansky)"wolfc" wrote:
We should not have a isVolatile on MethodInfo, but isBridge. In theory it can change in the future.
No, isVolatile is legit.
Perhaps we can add isBridge, which would currently just call isVolatile for MethodInfo.
Once 'bridge' can be referenced via JDK, then we can change the impl.// Bits not (yet) exposed in the public API either because they // have different meanings for fields and methods and there is no // way to distinguish between the two in this class, or because // they are not Java programming language keywords static final int BRIDGE = 0x00000040;
-
12. Re: Generic properties on interface and impl class
starksm64 Oct 30, 2007 3:13 PM (in response to aloubyansky)There is no isVolatile in the java.lang.reflect.Method interface, but there is an isBridge() method. I would guess the modifiers bit mask has the Modifier.VOLATILE set for a bridge method, but have not checked that.
-
13. Re: Generic properties on interface and impl class
alesj Oct 30, 2007 7:38 PM (in response to aloubyansky)We can do 'isBridge' if that is more accurate.
Like I said, adding that to MethodInfo, and simply calling isVolatile, as JDK currently does it.