Page History

...

• javax.script APIs engine.eval(String) and engine.eval(Reader): These scripts are treated as sandbox code  - except for jdk.nashorn.api.scripting.URLReader. If you pass URLReader, script origin based on that URL associated is used. So, security permissions are based on the script origin URL.
  
  

• Calling ECMAScript "eval" builtin function: Script is treated as "sandbox" and hence gets only sandbox permissions.
  
  
• Calling "load" function with a file File/URL: This method and command line method both associate a URL/File origin for the script and hence script URL/File based fine-grained permission can be used. When you run with security manager on, you can specify permissions for specific script URLs or file: URLs
  
  

• Calling "load" from a script object as in like load({ name: "foo", script: str}): This is equivalent to "eval" - but it associates a name with script and so stack traces will have nice readable name instead of <eval>. "str" may be computed or a literal. It does not matter. But, script is treated as 'sandbox'.
  
  
• Calling loadWithNewGlobal function: This is similar to load [all options are load available]. The difference is that it creates a new EMCAScript global scope and loads your code into that global. This avoids global namespace pollution. Note that security access permission is based on script origin URL or File if you pass a URL or a File. If you use loadWithNewGlobal as
  
  
• loadWithNewGlobal from a script object like loadWithNewGlobal({ name: "foo", script: str}), the : The script is treated as a sandbox.
  
  
• javax.script APIs engine.eval(Reader, Bindings) and engine.eval(String, Bindings): This is similar to the other engine.eval methods in that these are sandbox script evaluations unless Reader is a URLReader. But, these methods create/associate a fresh ECMAScript global and load code there [similar to loadWithNewGlobal in that sense]

...