[ 
https://issues.apache.org/jira/browse/TAP5-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14045696#comment-14045696
 ] 

Lance commented on TAP5-1493:
-----------------------------

Not sure if it helps, but many years ago I noticed that in circumstances like 
this, there were two instances of the `java.lang.reflect.Method`. This could be 
seen in either Class.getMethods() or Class.getDeclaredMethods() (I can't 
remember which).

>From memory, I think you distinguish between them via `Method.getModifiers()`. 
>I think the base method returned `true` from 
>`Modifiers.isVolatile(method.getModifiers()))`. Perhaps a fix could be to use 
>the non-volatile version of the method?

Further reading here https://directwebremoting.atlassian.net/browse/DWR-125



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

Reply via email to