Generic properties on interface and impl class

[aloubyansky]

This issue was initially discussed in XB forums
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4099492#4099492

The testcase is very simple and is in the mc testsuite

package org.jboss.test.beaninfo.test;
public class BeanInfoUnitTestCase extends AbstractBeanInfoTest
public void testGenericInterfaceImpl() throws Throwable

During the metadata discussion we decided it was a bug in the BeanInfo API. I haven't created a Jira issue for this yet though.

[aloubyansky]

It seems like this issue actually affects a number of tests in xb project, not just the recently discovered.

[alesj]

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?

[aloubyansky]

Yes, the methods are there. I would expect the property type to be java.lang.String, not java.lang.Object.

[alesj]

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 AbstractBeanInfoFactory

 if (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.

[alesj]

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. :-)

[starksm64]

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.

[alesj]

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. :-)

[kabirkhan]

"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.

[starksm64]

Ok, then yes, we should be filtering volatile methods out of the property accessor candidates.

[wolfc]

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.

[alesj]

"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;

[starksm64]

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.

[alesj]

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.