[jira] [Resolved] (SCXML-245) Reimplement Nashorn Javascript Evaluator

["Woonsan Ko (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SCXML-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Woonsan Ko resolved SCXML-245.
------------------------------
    Resolution: Fixed
      Assignee: Ate Douma  (was: Woonsan Ko)

> Reimplement Nashorn Javascript Evaluator
> ----------------------------------------
>
>                 Key: SCXML-245
>                 URL: https://issues.apache.org/jira/browse/SCXML-245
>             Project: Commons SCXML
>          Issue Type: Improvement
>            Reporter: Ate Douma
>            Assignee: Ate Douma
>             Fix For: 2.0
>
>
> The current Javascript context binding can be drastically improved and simplified by using a binding which only delegates to the SCXML context it wraps, and not (also) another binding and/or the Nashorn Global binding.
> The SCXML context will be bound to the ScriptEngine.GLOBAL_SCOPE and for the ScriptEngine.ENGINE_SCOPE the default Nashorn binding will be used, which thereby will also hold and maps to the Nashorn Global itself.
> Javascript script execution can add/modify new or 'shadowed' variables into the Nashorn Global, these need to be copied/merged back into the SCXML context after execution.
> A separate ScriptContext will now be used for each JSEvaluator, to be shared/reused across invocations. JSEvaluator instances therefore must be and only can be used for a single SCXML instance (btw: like with the GroovyEvaluator).
> As the Nashorn Global cannot be serialized, modifications made from within Javascript execution to the Global objects themselves (e.g. bind extra properties/functions) will NOT be retained after serialization, and likewise creating Javascript objects and 'returning' them to (using within) the SCXML context will likewise NOT be serializable.
> Javscript based SCXML instance serialization therefore is limited within these constraints! 
> To support the SCXML requirements for protected system variables, the Javascript Global will be initialized before first access with specific "init_global.js" script, loaded as classpath resource,
> which will bind these protected SCXML system properties into the Javscript Global state, as well as the required SCXML In() predicate function.
> Note that this uses the ECMAScript Object.bindProperties function, which is NOT (yet) implemented by the Mozilla Rhino engine, which thus cannot be used anymore, not even as optional extra dependency! 
> The Javascript engine itself, as the init_global.js script resource, is now created statically only once and reused across all SCXML instances, which might give a performance improvement as well. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)