// JavaScript
for( prop in this ) {
print( "this[" + prop + "] == " + this[prop] + "\n" ); }
// Java
jsEngine.eval(
"for( prop in this ) {
print( \"this[\" + prop + \"] == \" +
this[prop] + \"\\n\" ); }";
);
Why is it that when I use plain old JDK 6 JSR-223 (Rhino 1.6R2), the
JavaScript engine already knows about:
this[println] ==
function println(str) {
print(str, true);
}
this[context] == javax.script.SimpleScriptContext@2ab653
this[print] ==
function print(str, newline) {
if (typeof (str) == "undefined") {
str = "undefined";
} else {
if (str == null) {
str = "null";
}
}
var out = context.getWriter();
out.print(String(str));
if (newline) {
out.print("\n");
}
out.flush();
}
this[org] == [JavaPackage org]
this[edu] == [JavaPackage edu]
this[javax] == [JavaPackage javax]
this[com] == [JavaPackage com]
this[net] == [JavaPackage net]
And when I download the Mozilla Rhino distribution and put js.jar on the
path (Rhino 1.6R5), the JSR-223 engine has these predefined functions:
this[context] == javax.script.SimpleScriptContext@1827d1
this[print] ==
function print(str) {
if (typeof (str) == "undefined") {
str = "undefined";
} else {
if (str == null) {
str = "null";
}
}
context.getWriter().println(String(str));
}
And if I invoke Rhino independent of the JSR-223 interface (e.g.,
through the Rhino Shell or Rhino Debugger tools), then a set of
functions including print() are defined in some global context by
org.mozilla.javascript.tools.shell.Global.initStandardObjects() (even
though I can't print them out using the "this[key]" trick as in the
other engines)...
And when I run in NetBeans Phobos I get:
this[module] == [object Object]
this[application] == [object Object]
this[invocation] == [object Object]
this[response] ==
com.sun.phobos.container.grizzly.impl.GrizzlyResponse@112336a
this[managedBeans] == [object Object]
this[globals] == [object Object]
this[javax.script.filename] == /application/script/index.js
this[request] ==
com.sun.phobos.container.grizzly.impl.GrizzlyRequest@5e4157
this[prefix] == undefined
this[context] == javax.script.SimpleScriptContext@1bb22cb
this[library] == [object Object]
this[load] ==
function (name) { var services =
Packages.com.sun.phobos.container.PhobosRuntime.getGlobalContext().get("services");
if (services.resource.isResourcePresent(name)) {
services.scripting.evalScript(name, context); } }
this[controller] == [object Object]
this[writer] ==
com.sun.phobos.container.grizzly.impl.GrizzlyWriter@121cdab
OK, obviously in the last case I'm in a servlet environment.
But why is there such a difference in the available methods in different
engines?
Thanks!
--Andrew Mickish
> And if I invoke Rhino independent of the JSR-223 interface (e.g.,
> through the Rhino Shell or Rhino Debugger tools), then a set of
> functions including print() are defined in some global context by
> org.mozilla.javascript.tools.shell.Global.initStandardObjects() (even
> though I can't print them out using the "this[key]" trick as in the
> other engines)...
Object properties in JavaScript can be defined as non-enumerable such
that they wouldn't show up in a for (name in object) loop.
> But why is there such a difference in the available methods in different
> engines?
JavaScript is designed as a scripting environment used for
manipulating a host environment. (Hopefully I am not doing too much
violence to the true original intent by putting this in my own words
-- egads, Brendan reads this newsgroup.) Familiar examples of host
objects include "window" and "document" when one is doing JavaScript
web programming in the host environment of a web browser; they are
exposed to scripts but are not implemented using JavaScript code.
Rhino is an embeddable JVM JavaScript engine; one embedding is
provided with its download (the JavaScript shell you mentioned
third). The JSR-223 people (who are separate from the Mozilla
project) provide their own embedding that plugs Rhino into the JSR 223
framework, and the Phobos people provide their own embedding.
Application-specific embeddings are possible too (so that you could
expose Java objects in your application as JavaScript objects).
So the embedder decides what host objects are available to the
scripter, and hence the results you'll see across embeddings will be
inconsistent (but hopefully in a way that helps meet the needs of the
users of each embedding).
-- David P. Caldwell
http://www.inonit.com/