On 13.11.2019 19:50, Kevin Rushforth wrote:
>
> On 11/13/2019 9:42 AM, Rony G. Flatscher wrote:
>> Will come up with a short reproducible testcase in ooRexx with brief
>> comments such that the testcase
>> could be understood without the runtime (ooRexx reads almost like
>> pseudo-code).
>>
>> To reproduce the testcase one would need ooRexx and the Java bridge
>> BSF4ooRexx (all opensource) for
>> which I could come up with a zip-archive (assuming binaries within should be
>> 64-bit) and a script to
>> set up the environment either for Windows, Linux or MacOS, whatever you
>> advise. Would that be o.k.?
>
> We prefer not to rely on third-party libraries for test cases. In any case we
> would not be able to
> use that for a regression test / unit test.
Yes, this is understandable.
> How hard to you think it would be to use NashornScriptEngine for a test case?
Probably impossible. Have researched NashornScriptEngine a little bit for a
couple of hours now in
order to assess it with respect to writing a testcase to demonstrate the
problem.
According to [1] the implementation has some Nashorn specific uses with respect
to the ENGINE_SCOPE
Bindings like:
- "... The default context's ENGINE_SCOPE is a wrapped instance of ECMAScript
"global" object -
which is the "this" in top level script expressions. ..."
- "... Please note that the context's GLOBAL_SCOPE Bindings and nashorn global
object are
different. Nashorn's global object is associated with ENGINE_SCOPE and not with
GLOBAL_SCOPE.
GLOBAL_SCOPE object of default script context is a javax.script.SimpleBindings
instance. ..."
- "... If you create a new ScriptContext object and use it to evaluate scripts,
then ENGINE_SCOPE of
that context has to be associated with a nashorn Global object somehow - or
else script execution is
not possible with that context - this is because evaluated script expects
standard ECMAScript global
builtins always. ..."
- "... But, user can supply any ScriptContext implementation containing any
Bindings object as
ENGINE_SCOPE, nashorn engine cannot always assume ENGINE_SCOPE Bindings to be
backed by a nashorn
Global instance. Nashorn engine checks if ENGINE_SCOPE of the ScriptContext is
backed by a Nashorn
Global object or not. If not, it creates a fresh Bindings backed by a nashorn
Global instance and
associates the same with the ENGINE_SCOPE that the user provided. ..."
- "... Limitations/Known issues / While nashorn attempts to give a seamless
illusion of
ScriptObjectMirrors and JSObjects, not every operation and script API (JSON,
Array, Function's
properties/functions) treats ScriptObjectMirror and
jdk.nashorn.internal.runtime.ScriptObject
uniformly. There are places where ScriptObjects work as expected but if you
pass ScriptObjectMirror
or your own JSObject implementation, it won't work as expected. ..."
[2] states: "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."
In addition [3] indicates that scripts themselves should not get access to
ScriptEngine.FILENAME.
Indeed, adding the entry ScriptEngine.FILENAME to the NashornScriptEngine
supplied ENGINE_SCOPE
Bindings (which will be of type "jdk.nashorn.api.scripting.ScriptObjectMirror")
will not leave that
entry in the Bindings.
Also, invoking a Javascript script stored in a file via ScriptEngine.eval()
does not make the
arguments (entry ScriptEngine.ARGV) available to the invoked Javascript script
(i.e.
"arguments.length" will return 0), e.g. in the following testscript.js:
print( "hi, this is from 'testargs.js', arguments.length="+arguments.length);
print( "arguments.length: " + arguments.length );
print( "---")
func1 ( "uno", "deux", 3);
function func1(a, b, c) {
print( "--> func1(a, b, c) - arguments.length: " + arguments.length );
print( "\ta: "+ a + " / arguments[0]: " + arguments[0] );
print( "\tb: "+ b + " / arguments[1]: " + arguments[1] );
print( "\tc: "+ c + " / arguments[2]: " + arguments[2] );
}
Doing a ScriptEngine.eval() with the ENGINE_SCOPE Bindings possessing the
argument entry by the name
of ScriptEngine.ARGV will yield the following output in this case:
hi, this is from 'testargs.js', arguments.length=0
arguments.length: 0
---
--> func1(a, b, c) - arguments.length: 3
a: uno / arguments[0]: uno
b: deux / arguments[1]: deux
c: 3 / arguments[2]: 3
[1] Sundararajan A., "Nashorn jsr223 engine notes":
<https://wiki.openjdk.java.net/display/Nashorn/Nashorn+jsr223+engine+notes>
[2] Sundararajan A., "Nashorn, javax.script.filename, and load()":
<http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-July/004932.html>
[3] "JDK-8050432 : javax.script.filename variable should not be enumerable with
nashorn engine's
ENGINE_SCOPE bindings":
<https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8050432>
[4] Oracle, "Java Platform, Standard Edition Nashorn User's Guide":
<https://docs.oracle.com/javase/8/docs/technotes/guides/scripting/nashorn/toc.html>
---
So concluding that the NashornScriptEngine will not be an implementation that
could be used to
create a testcase to demonstrate the problem and to create a testunit, because
of its specific
implementation that
a) swallows the ScriptEngine.FILENAME
(https://docs.oracle.com/javase/8/docs/api/javax/script/ScriptEngine.html#FILENAME)
entry and
b) does not honor the ScriptEngine.ARGV (cf.
<https://docs.oracle.com/javase/8/docs/api/javax/script/ScriptEngine.html#ARGV>)
entry.
Would you have other suggestions for scripting engines that you think could be
used instead, such
that I can take a look at its implementation and try to create a testcase with
it?
---rony
