[
https://issues.apache.org/jira/browse/TAP5-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18131861#comment-18131861
]
ASF subversion and git services commented on TAP5-2842:
-------------------------------------------------------
Commit 98e909b112140bfaa5db91e5ccb66a98abe8b47a in tapestry-5's branch
refs/heads/property-expression-parser from Ben Weidig
[ https://gitbox.apache.org/repos/asf?p=tapestry-5.git;h=98e909b11 ]
TAP5-2842: Prefer declared methods over bridge methods in property expressions
A method invocation used the first method of Class.getMethods() with a
matching name and parameter count. That order is unspecified, so a
method implementing a generic interface could resolve to its bridge
method, and the conduit got the erased type Object instead of the
declared return type.
A bridge method is now used only when nothing else matches. A public
method inherited from a non-public class is reachable through a bridge
method alone.
> Property expression method invocation may resolve to a bridge method
> ---------------------------------------------------------------------
>
> Key: TAP5-2842
> URL: https://issues.apache.org/jira/browse/TAP5-2842
> Project: Tapestry 5
> Issue Type: Bug
> Components: beanmodel
> Affects Versions: 5.10.0
> Reporter: Ben Weidig
> Assignee: Ben Weidig
> Priority: Minor
>
> h2. Summary
> {{PropertyConduitSourceImpl.findMethod()}} returns the first method of
> {{Class.getMethods()}} that matches the name and the parameter count.
> However, the order of {{getMethods()}} is unspecified.
> For a class implementing a generic interface, such as
>
> {code:java}
> public interface Producer<T>{
> T produce();
> }
> public class LongProducer implements Producer<Long> {
> public Long produce()
> { ... }
> }
> {code}
> {{getMethods()}} returns both {{Long produce()}} and the compiler-generated
> bridge {{{}Object produce(){}}}.
> If the bridge comes first, the expression "{{{}produce(){}}}" resolves to it
> and the conduit reports the property type {{Object}} instead of {{{}Long{}}}.
> The value is still correct, though, because the bridge delegates to the real
> method.
> The order differs between environments.
> It was observed on Java 11, but not on Java 21/25.
> h2. Fix
> Prefer a non-bridge method, and fall back to a bridge only when nothing else
> matches.
> A public method inherited from a non-public class is reachable only through a
> bridge method, so bridges cannot be skipped entirely.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
