[ https://issues.apache.org/jira/browse/TAP5-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14046022#comment-14046022 ]
Hudson commented on TAP5-1493: ------------------------------ SUCCESS: Integrated in tapestry-trunk-freestyle #1259 (See [https://builds.apache.org/job/tapestry-trunk-freestyle/1259/]) Fix an NPE I've introduced while investigating TAP5-1493. (thiagohp: rev fd2714ccea5c9b51e7f33313d92a1608d0d9a4e1) * tapestry-ioc/src/main/java/org/apache/tapestry5/ioc/internal/services/ClassPropertyAdapterImpl.java > 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)