commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Woonsan Ko (JIRA)" <>
Subject [jira] [Resolved] (SCXML-245) Reimplement Nashorn Javascript Evaluator
Date Tue, 05 Jan 2016 05:03:39 GMT


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

> Reimplement Nashorn Javascript Evaluator
> ----------------------------------------
>                 Key: SCXML-245
>                 URL:
>             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
> 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

View raw message