[ https://issues.apache.org/jira/browse/TAP5-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14045823#comment-14045823 ]
Lance commented on TAP5-1493: ----------------------------- I just read Alexander Gavrilov's comment above. As he said, you should be able to use {code}Method.isBridge(){code} And use the non-bridge method (instead of Modifiers.isVolatile(...) as i suggested). > Property expressions on properties that are covariant on a base class use the > type of the base class property, not the covariant subclass > ----------------------------------------------------------------------------------------------------------------------------------------- > > Key: TAP5-1493 > URL: https://issues.apache.org/jira/browse/TAP5-1493 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core, tapestry-ioc > Affects Versions: 5.2 > Reporter: Howard M. Lewis Ship > Priority: Critical > Labels: month-of-tapestry > Fix For: 5.4 > > > public abstract class AbstractFoo > { > public abstract AbstractBar getBar(); > } > public class Foo extends AbstractFoo > { > public Bar getBar(); > } > Here property bar is covariant; the subclass (Foo) changes the type of the > return value (from AbstractBar to just Bar). Assuming that Bar is a subclass > of AbstractBar, that's fine. > The bug is that in this circumstance, the PropertyConduitSource sees the type > of > property "bar" of class Foo as AbstractBar, not Bar. > Interestingly, a little debugging showed that the getter method for property > bar was "public AbstractBar Foo.getBar()" ... in other words, much like with > Generics, covariant return types may be largely > a fiction of the compiler inserting the necessary casts in place. -- This message was sent by Atlassian JIRA (v6.2#6252)