commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ate Douma (JIRA)" <>
Subject [jira] [Created] (SCXML-245) Reimplement Nashorn Javascript context binding
Date Tue, 29 Dec 2015 12:38:49 GMT
Ate Douma created SCXML-245:

             Summary: Reimplement Nashorn Javascript context binding 
                 Key: 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.

This way, all Javascript context binding changes only will end up in the SCXML context and
the Nashorn Global can remain (and should be) 'untouched'. 
This is largely similar to how the Groovy context binding works.
The Nashorn Global binding will be the only 'exception' to this: the new JSBinding will keep
that one variable (with key " separate, not storing it in the SCXML context
This will also simplify the SCXML context serialization (as the Nashorn Global is NOT serializable).

Pre-requisite is that for each SCXML document+JSEvaluator only a single script engine will
be used and all script/condition evaluations are using the same Nashorn Global. Which actually
will give a performance improvement as well.

The only 'limitation' will be that Nashorn Global modifications (like modifications made to
Javscript global objects like Object) will also NOT be stored in the SCXML context, and therefore
not be serialized either.
But then, those weren't serializable to begin with, so this is an intrinsic limitation of
using the Javascript engine anyway.
Meaning: when using the Javascript engine, global modifications cannot and won't be serialized.
However, as a single and separate engine will be used ('attached') for each SCXML instance,
and (therefore) share a single Nashorn Global, as long as the SCXML instance doesn't need
to be (de)serialized, using global modifications should just 'work' within the context of
that single SCXML instance execution.   

This message was sent by Atlassian JIRA

View raw message