Re: the ScriptingMojo

On Sun, Aug 23, 2020 at 1:43 AM Chapman Flack <chap(at)anastigmatix(dot)net> wrote:

> On 08/22/20 15:33, Chapman Flack wrote:
> > Ok, I removed the parallel() and now graal also complains about the SAM
> > cast. This puzzles me because I thought both engines were intended to
> > support that, so I'll keep playing with it a bit.
>
> If I make the attached changes, both nashorn and graal seem to be happy.
>
> It appears that, when invoking a method /of a Java object/, they
> recognize when its parameter type is a SAM interface, and do the magic
> to present a JavaScript function as an implementation of that.
>
> We might just be asking for too many layers of magic when we start by
> binding a Java lambda into the script engine (which probably wraps one
> layer of magic over it to make it look like a JS function), and then try
> to pass a JS function as a parameter needing its own magic wrapping to
> appear as a Java SAM interface, and the engine may not see through the
> first layer of magic to realize it needs to add the second.
>
> "Thing" as a class name is just proof-of-concept of course. :) I had
> been wondering earlier if it might be useful to make PGXSUtils instantiable
> and bind an instance of it into the script; its constructor could take the
> MavenProject and Log and those wouldn't have to be passed around as much.
> It would still be possible to bind selected methods of it directly with
> names of their own for convenience, but other methods could just be
> accessible as utils.method() and I think that would solve this casting
> issue.
>
> Regards,
> -Chap
>

Sounds good to me. I'll make the changes to the PGXSUtils class.
Regards,
Kartik