Well, filterInternalObjects itself doesn’t change the method handle type. I guess what happens is that the delegate BeansLinker.getGuardedInvocation returned a handle that it already adapted to the call site type. But you’re right that the filterInternalObjects here was both redundant and harmful; BeanLinker calls it where necessary.
+1. Glad you got to the bottom of this, it felt really scary how the original reproducer seemingly depended on the shape of not-yet-evaluated expressions (I completely forgot about shared scope…) Attila. > On 25 Jan 2017, at 17:32, Hannes Wallnöfer <hannes.wallnoe...@oracle.com> > wrote: > > The problem is that the first invocation of filtertInternalObjects (that > happens closer to the target handle) changes the method handle’s parameter > type from java.util.List to java.lang.Object, so the outer > filtertInternalObjects invocation did not see the List target type. > > Hannes > >> Am 25.01.2017 um 17:21 schrieb Attila Szegedi <szege...@gmail.com>: >> >> Oh, great. I was just starting at this for a bit (after I saw you updated >> the JIRA), and was definitely starting to suspect the filterInternalObjects >> call in NashornBeansLinker. It still worries me that filtering would add a >> script object mirror wrapper – the method handle’s parameter is typed as >> List, isn’t it? DefaultInternalObjectFilter should only operate on >> parameters declared as Object. >> >> Attila. >> >>> On 25 Jan 2017, at 17:05, Hannes Wallnöfer <hannes.wallnoe...@oracle.com> >>> wrote: >>> >>> Please review: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8172006 >>> Webrev: http://cr.openjdk.java.net/~hannesw/8172006/webrev.00/ >>> >>> The final invocation of linkerServices.filterInternalObjects was redundant, >>> and in fact caused the argument to be converted to ScripObjectMirror when >>> the actual target type was java.util.List. As far as I can tell, >>> linkerServices.filterInternalObjects is called elsewhere for all types of >>> invocations. Existing tests pass, and I added a few more. >>> >>> Thanks, >>> Hannes >> >
