szegedia at gmail.com
Wed Jan 25 16:39:16 UTC 2017
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.
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…)
> On 25 Jan 2017, at 17:32, Hannes Wallnöfer <hannes.wallnoefer at 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.
>> Am 25.01.2017 um 17:21 schrieb Attila Szegedi <szegedia at 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.
>>> On 25 Jan 2017, at 17:05, Hannes Wallnöfer <hannes.wallnoefer at 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.
More information about the nashorn-dev