-
Type:
Enhancement
-
Resolution: Not an Issue
-
Priority:
P4
-
None
-
Affects Version/s: 7
-
Component/s: core-libs
-
x86
-
windows_7
A DESCRIPTION OF THE PROBLEM :
The API does not specify if eval() is thread-safe. The implications are ambiguous:
A. The existence of ScriptEngine.put() and ScriptEngine.get() would clearly imply that eval() without supplying a ScriptContext is not thread-safe.
B. The existence of ScriptEngine.eval() with a ScriptContext as a parameter eludes to the possibility of that version of eval() being thread-safe.
Either scenario is plausible and useful. The fact that this is not specified causes a few problems:
1. It makes it difficult to determine the proper way to enhance the API to allow a running eval() to be terminated.
2. It makes it impossible to know how to best utilize the ScriptEngine in a multi-threaded environment. Do you have to allocate a new ScriptEngine for each concurrently running script, or is it safe to use some versions of eval() simultaneously?
3. It makes it more difficult to provide optimized engine implementations because you cannot be sure where it is safe to cache instance-specific data without potentially having your implementation broken by a future clarification of the API (i.e., do you cache to the ScriptContext, the ScriptEngine, or is neither safe?). Not to mention you can't optimize for a particular use case because of the uncertainty of #2.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Please indicate if the various versions of eval() are thread-safe or not.
ACTUAL -
Nothing
URL OF FAULTY DOCUMENTATION :
http://download.oracle.com/javase/7/docs/api/javax/script/ScriptEngine.html
The API does not specify if eval() is thread-safe. The implications are ambiguous:
A. The existence of ScriptEngine.put() and ScriptEngine.get() would clearly imply that eval() without supplying a ScriptContext is not thread-safe.
B. The existence of ScriptEngine.eval() with a ScriptContext as a parameter eludes to the possibility of that version of eval() being thread-safe.
Either scenario is plausible and useful. The fact that this is not specified causes a few problems:
1. It makes it difficult to determine the proper way to enhance the API to allow a running eval() to be terminated.
2. It makes it impossible to know how to best utilize the ScriptEngine in a multi-threaded environment. Do you have to allocate a new ScriptEngine for each concurrently running script, or is it safe to use some versions of eval() simultaneously?
3. It makes it more difficult to provide optimized engine implementations because you cannot be sure where it is safe to cache instance-specific data without potentially having your implementation broken by a future clarification of the API (i.e., do you cache to the ScriptContext, the ScriptEngine, or is neither safe?). Not to mention you can't optimize for a particular use case because of the uncertainty of #2.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Please indicate if the various versions of eval() are thread-safe or not.
ACTUAL -
Nothing
URL OF FAULTY DOCUMENTATION :
http://download.oracle.com/javase/7/docs/api/javax/script/ScriptEngine.html