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 >>> >> >
