One of the awesome things of having a big open source community is that it makes Activiti run on platforms and configuration which we don’t have in our automated QA environment. Regardless of how many people/time/money you have, there’s always going to be a funny configuration that makes the software behave just differently.

So one of the issues discovered and reported by Brian Showers in the Activiti forum, is that the test suite doesn’t run green on JDK 1.7.0._17. And indeed,  my dev machine didn’t have the latest JDK installed nor had the QA at the time of writing.

So what is the problem? Well, in Activiti when using a scriptTask, you can write something like

<scriptTask id="myScript" scriptFormat="JavaScript">
  <script><![CDATA[
    var sum = a + b;
  ]]></script>
</scriptTask>

The variable sum will be automatically saved as a process variable (unless you set the property “activiti:autoStoreVariables=’false'” on the scriptTask). This has worked since whatever version of Activiti we introduced scripting. So it has worked for JDK 5, 6 and until recently 7. But on the latest JDK, at the time of writing 1.7.0_17, it doesn’t run. It throws an exception:

org.activiti.engine.ActivitiException: couldn’t find a variable type that is able to serialize sun.org.mozilla.javascript.internal.Undefined@7216df
at org.activiti.engine.impl.variable.DefaultVariableTypes.findVariableType(DefaultVariableTypes.java:62)
at org.activiti.engine.impl.persistence.entity.VariableScopeImpl.createVariableInstance(VariableScopeImpl.java:359)
at org.activiti.engine.impl.persistence.entity.VariableScopeImpl.createVariableLocal(VariableScopeImpl.java:292)
at org.activiti.engine.impl.persistence.entity.VariableScopeImpl.createVariableLocal(VariableScopeImpl.java:279)
at org.activiti.engine.impl.persistence.entity.VariableScopeImpl.setVariable(VariableScopeImpl.java:254)
at org.activiti.engine.impl.persistence.entity.VariableScopeImpl.setVariable(VariableScopeImpl.java:237)
at org.activiti.engine.impl.scripting.ScriptBindings.put(ScriptBindings.java:83)
at javax.script.SimpleScriptContext.setAttribute(SimpleScriptContext.java:228)
at com.sun.script.javascript.ExternalScriptable.put(ExternalScriptable.java:182)
at sun.org.mozilla.javascript.internal.ScriptableObject.defineProperty(ScriptableObject.java:1394)
at sun.org.mozilla.javascript.internal.ScriptRuntime.initScript(ScriptRuntime.java:3239)
at sun.org.mozilla.javascript.internal.Interpreter.initFrame(Interpreter.java:2695)
at sun.org.mozilla.javascript.internal.Interpreter.interpret(Interpreter.java:844)
at sun.org.mozilla.javascript.internal.InterpretedFunction.call(InterpretedFunction.java:162)
at sun.org.mozilla.javascript.internal.ContextFactory.doTopCall(ContextFactory.java:429)
at com.sun.script.javascript.RhinoScriptEngine$1.superDoTopCall(RhinoScriptEngine.java:116)
at com.sun.script.javascript.RhinoScriptEngine$1.doTopCall(RhinoScriptEngine.java:109)
at sun.org.mozilla.javascript.internal.ScriptRuntime.doTopCall(ScriptRuntime.java:3161)
at sun.org.mozilla.javascript.internal.InterpretedFunction.exec(InterpretedFunction.java:173)
at sun.org.mozilla.javascript.internal.Context.evaluateReader(Context.java:1159)
…

So it seems that in the latest JDK 7 version, somehow the class that is used to represent a scripting variable in the JDK isn’t Serializable anymore. However, if you switch your script to

<scriptTask id="myScript" scriptFormat="JavaScript">
  <script><![CDATA[
    var sum = a + b;
    execution.setVariable("sum", sum);
  ]]></script>
</scriptTask>

It just works. When I debugged, an object of the class ‘Double’ was passed instead of ‘Undefined’ in the first example. So when calling a Java object from a script, some auto-coercion/conversion is happening … which is not happening in the first example. Unfortunately all the classes involved are internal classes (eg sun.javascript.xxxxx) so we can’t just force the conversion somehow as this would break on some systems.

So what options do we have

• The behavior we’re seeing is a bug in the JDK. It is fixed in a next release.
• The behavior is actually a fix for something broken in the past few years. Although I don’t think that Oracle would break backwards compatibility in a minor JDK release.

So the current thinking is that we wait a bit until next release. In the mean time, I’l try to figure out how to report a JDK bug.

People that are depending on the auto storage of variable will have to use the workaround with execution.setVariable(name, value); for the moment. If anybody has any input regarding this issue, please let us know!