Serialization of javascript lambdas

[Tristan Tarrant]

Yes, I don't expect them to be serializable, but just allow me to 
identify them.
Is there a way to intercept the generation of the MethodHandle so that 
it can be "decorated" with the original ScriptFunction ?

Under what circumstances would the ScriptFunctionData.needsCallee() be 
triggered ?

Tristan

On 28/06/16 06:31, Sundararajan Athijegannathan wrote:
> No, none of the nashorn objects are Serializable and that is by design!
> As you've found out, Nashorn objects are too 'tied' to the current
> execution state - in which most of the objects are not Serializable.
>
> -Sundar
>
>
> On 6/27/2016 8:56 PM, Tristan Tarrant wrote:
>> Hi all,
>>
>> I've been playing with Nashorn in combination with the Streams API in
>> the context of being able to run functions in a distributed
>> environment (i.e. Infinispan's server-side scripting).
>>
>> In plain Java, a lambda has a SerializedLambda form which basically
>> encapsulates all of the coordinates that allow the recreation of a
>> MethodHandle on the remote side. This obviously assumes that the
>> remote classloader has access to the exact same bytecode.
>>
>> Nashorn lambdas however do not (or cannot?) have a SerializedLambda
>> representation, so I'm looking for an alternative way to identify them.
>>
>> Consider the following snippet which is a (dumb) example:
>>
>> map.entrySet().stream().map(function(e) e.getValue())
>>
>> On the Java side, the map method takes a Function parameter.
>> Inspecting the parameter I see that Nashorn has created an adapter
>> class at runtime
>> (jdk.nashorn.javaadapters.java.util.function.Function) and that the
>> apply() method of that class is a BoundMethodHandle$Species_LL.
>> Unfortunately there is no reference to the original ScriptFunction,
>> which would otherwise allow me to invoke toSource() on it, simply
>> serialize that string, send it to the remote node, compile it and
>> invoke it.
>>
>> Inspecting further I've understood that anonymous javascript functions
>> get bound to method handles identified by a name in the form of L:x
>> where "x" looks like a counter. Compiling the same script on multiple
>> nodes, the identifier is consistent, however I've found no way to
>> invoke those methodhandles on the remote nodes.
>> I've noticed that it's possible to get the ScriptFunction passed as a
>> parameter (needsCallee), but I haven't understood how to do that.
>>
>> So my question is: given a Nashorn Java adapter generated from a
>> ScriptFunction, is there a way for me to identify the ScriptFunction
>> it originates from and to invoke that same function "by name" on a
>> remote node which has the same script ?
>>
>> Thanks
>>
>> Tristan
>>
>

-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat