What is the lifecycle and concurrency semantics of Rhino Script Engine

Question

I am interested in the lifecycle and concurrency semantics of (Rhino) Script Engine and associated classes. Specifically:

1. Is Bindings supposed to be thread safe?
2. Should multiple threads be allowed to share a single ScriptEngine instance?
3. ... or should each thread construct a short-lived instance?
4. ... or keep them in a pool?
5. What happens if multiple threads concurrently call ScriptEngine.eval(...)?
6. Same questions for CompiledScript instances
7. Same questions for interface implementations generated using Invocable.getInterface(...)?
8. Presumably, objects placed in Bindings follow Java's garbage collection. What about garbage collection of objects that don't end up in the bindings?

Answer 1

So I've run the experiment and the Rhino engine reports "Mozilla Rhino" is MULTITHREADED which the JavaDocs asserts

"MULTITHREADED" - The engine implementation is internally thread-safe and scripts may execute concurrently although effects of script execution on one thread may be visible to scripts on other threads."

Here's the code...it looks threadsafe to me, as long as the bindings you pass in are threadsafe too.

package org.rekdev;
import java.util.*;
import javax.script.*;
public class JavaScriptWTF {
    public static void main( String[] args ) {
        ScriptEngineManager mgr = new ScriptEngineManager();
        List<ScriptEngineFactory> factories = mgr.getEngineFactories();
        for ( ScriptEngineFactory factory : factories ) {
            System.out.println( String.format(
                    "engineName: %s, THREADING: %s",
                    factory.getEngineName(),
                    factory.getParameter( "THREADING" ) ) );
        }
    }
}

...the output is...

engineName: AppleScriptEngine, THREADING: null
engineName: Mozilla Rhino, THREADING: MULTITHREADED

To answer your exact question...

1. Is Bindings supposed to be thread safe?
   It sounds to me that it is your responsibility to make them Thread-safe. In other words, pass in only immutable objects and whether the engine is Thread-safe or not becomes a non-issue.

2. Should multiple threads be allowed to share a single ScriptEngine instance?
   It sounds to me like they can, but the key is the state sharing that can occur through the Bindings. Immutable objects are your friend.

3. ...or should each thread construct a short-lived instance?
   It seems to me that the best way to think of this is that each execution of eval is a short lived instance.

4. ... or keep them in a pool?
   In this day and age attempting to pool resources on your own is rarely a good idea. Give the short-lived instance a shot, measure its performance, and work out from there.

5. What happens if multiple threads concurrently call ScriptEngine.eval(...)?
   If I understand the Rhino engine's repsonse to MULTITHREADING correctly, ScriptEngine.eval should be fine with concurrent calls.

6. Same question for CompiledScript instances
   The JavaDocs state that "Changes in the state of the ScriptEngine caused by execution of the CompiledScript may visible during subsequent executions of scripts by the engine." http://docs.oracle.com/javase/6/docs/api/javax/script/CompiledScript.html. So they don't sound Thread-safe at all in an environment where you appear to be trying to minimize the number of ScriptEngine instances.

7. Same questions for interface implementations generated using Invocable.getInterface(...)? You are on your own here. I don't understand exactly why or when this capability would be used and it sounds to me like you may be "jumping the shark" here. If you want to go this deep into the scripting language, I recommend that you abandon JavaScript and look at Groovy for a more scriptable Java.

8. Presumably, objects placed in Bindings follow Java's garbage collection. What about garbage collection of objects that don't end up in the bindings?
   If they don't end up in bindings I expect them to be bound to the ScriptEngine and follow its lifecycle (based upon the docs that I have read). Pooling the ScriptEngine instances does not sound like a great idea.