Serialization of javascript lambdas

[Sundararajan Athijegannathan]

No, that is treated as an implementation detail. There is no way to
intercept method handle creation in java adapters. With jdk9, all 
jdk.nashorn.internal.* packages are concealed packages of nashorn module
(=> jdk.nashorn.internal.runtime.ScriptFunction is not an exposed type -
only accessible inside nashorn module).

-Sundar

On 6/28/2016 1:59 PM, Tristan Tarrant wrote:
> 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
>>>
>>
>