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 in
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 ?
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 ?
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 wit
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 coordin
