Any Benefits of using Spin over Javascript Objects when using javascript Scripting

Is there any benefits of using SPIN for JSON when using JS Scripting compared to using JSON.Parse() and JSON.stringify() to work with the JSON as a JS object?

1 Like

When you parse a string of json using JSON.parse you get a Object of jdk.nashorn.api.scripting.ScriptObjectMirror

although Cockpit is currently not able to read it:

Whenever you create a Javascript object and hand that to a Java API, the Nashorn engine wraps it in a ScriptObjectMirror. The class is not friendly to (de-)serialization and if I remember correctly instances are even tied to a ScriptingEngine instance. So if you want to set such objects as a process variable, I think a good practice is to transform it into a Spin JSON object (e.g. via S(JSON.stringify(javascriptObj)) in your script).


tied to script engine

Good point! That is a good insight.


on a side note: Why does JSON objects show up as red rows in Cockpit when inspecting the process variables of a process?

Can you please post a screenshot?


jsonExample.bpmn (4.8 KB)

Create JSON Var:
javascript Script Task (jsonOutput):

var jsonInfo = {"key1":"val1", "key2":"val2"};

Get property from JSON object:
javascript Script Task (property1):

var json = execution.getVariable("jsonOutput");


The validation of JSON and XML variables is currently not working correctly in Cockpit. I created a bug ticket for that:

1 Like

@sebastian.stamm thanks!


<?xml version="1.0" encoding=UTF-8"?><scriptObjectMirror>
 <proto xmlns:xsi=""

To point “The class (ScriptObjectMirror) is not friendly to (de-)serialization”
this is not true statement.
I was able to deserialize it successfully.
VariableMap variables = response.getVariables(); // response is response from camunda engine
Object objErrors= variables.get(“errors”);
ErrorModel errorModel =
new ObjectMapper().convertValue(((ScriptObjectMirror) objErrors).get(“0”), ErrorModel.class);