Nashorn, javax.script.filename, and load()

A. Sundararajan sundararajan.athijegannathan at oracle.com
Mon Jul 13 17:18:21 UTC 2015


Yes, I figured out that! "jrunscript" tool [which is a javax.script 
based tool independent of "nashorn"] sets javax.script.filename to be 
"<string>", when script is executed with -e option in command line.

As I mentioned "nashorn" itself does not set that value - it only uses 
it as name for script evaluated using "eval". And 'load' of nashorn uses 
the URL/file name of the loaded script as name for the script.

Summary: Nashorn uses javax.script.filename uses as "source name" of the 
generated class *only* for engine.eval calls. For "load", it uses the 
URL/file name of the loaded script as "source name". As for 
javax.script.filename variable, Nashorn never sets - only uses it.

"jrunscript"'s init.js defines it's own "load" if 'load' is not defined 
by underlying engine - For Rhino script engine in jdk7, that load is 
used [as embedded Rhino engine does not define load]. The "load" defined 
by init.js sets javax.script.filename to be the load url!!

If you consistently want javax.script.filename to be available for 
'load', I think you may have to save nashorn's load and define your own 
load which will set it and delegate to nashorn's load.

Hope this helps,
-Sundar

On Monday 13 July 2015 07:02 PM, David P. Caldwell wrote:
> Yes, this test "works" (as in demonstrates the problem):
>
> $ jrunscript -e
> "load('https://bitbucket.org/api/1.0/repositories/davidpcaldwell/slime/raw/launcher/rhino/jrunscript/api.js?test=filename')"
> stack = https://bitbucket.org/api/1.0/repositories/davidpcaldwell/slime/raw/launcher/rhino/jrunscript/api.js?test=filename
> javax.script.filename = <string>
>
> -- David.
>
> On Mon, Jul 13, 2015 at 8:59 AM, A. Sundararajan
> <sundararajan.athijegannathan at oracle.com> wrote:
>> Hi,
>>
>> AFAIK "javax.script.filename" is not set nashorn code anywhere. It is just
>> read to find source name for engine.eval calls.
>>
>> "load" builtin is not related to jsr-223 API. It works regardless of jsr-223
>> usage and so it does not use (nor writes!) javax.script.filename property.
>>
>> Is there a source link (the links in your email give me "error") or a
>> standalone test?
>>
>> Thanks,
>> -Sundar
>>
>>
>>
>> On Saturday 11 July 2015 01:59 AM, David P. Caldwell wrote:
>>> According to the documentation for javax.script.ScriptEngine, the key
>>> javax.script.ScriptEngine.FILENAME should point to the current file
>>> being executed. And it does, when executing a local file.
>>>
>>> But when executing a file from a URL using load(), it does not work. I
>>> can reliably get the URL using some rigamarole (see below), but I'd
>>> like a method that's portable across JDK 6-8 (or so).
>>>
>>> Here's the output of the following snippet when executing locally:
>>>
>>> Snippet:
>>> Packages.java.lang.System.out.println("stack = " + new
>>> Packages.java.lang.Throwable().getStackTrace()[0].getFileName());
>>> var global = (function() { return this; })();
>>> Packages.java.lang.System.out.println("javax.script.filename = " +
>>> global[String(Packages.javax.script.ScriptEngine.FILENAME)]);
>>>
>>> Output under JDK 8 locally:
>>> stack = rhino/jrunscript/api.js
>>> javax.script.filename = rhino/jrunscript/api.js
>>>
>>> Output under JDK 8 executing over HTTP via -e load('url'):
>>> stack =
>>> http://bitbucket.org/api/1.0/repositories/davidpcaldwell/jrunscript/raw/local/api.js?test=filename
>>> javax.script.filename = <string>
>>>
>>> And further inspection indicates that's a *string* "<string>"
>>>
>>> Here's JDK 7 for comparison:
>>>
>>> Output under JDK 7 locally:
>>> stack = NativeConstructorAccessorImpl.java
>>> javax.script.filename = rhino/jrunscript/api.js
>>>
>>> Output under JDK 7 executing over HTTP via -e load('url'):
>>> stack = NativeConstructorAccessorImpl.java
>>> javax.script.filename =
>>>
>>> http://bitbucket.org/api/1.0/repositories/davidpcaldwell/jrunscript/raw/local/api.js?test=filename
>>>
>>> Thoughts?
>>>
>>> -- David P. Caldwell
>>> http://www.davidpcaldwell.com/
>>



More information about the nashorn-dev mailing list