Re: the ScriptingMojo

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