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
