Scripting engine - Java 6

[debasish]

Hi -

I am a newbie wrt scripting in Java 6. I have 2 questions on this
topic :

a) With the current version of Java 6 distribution, the version of
Rhino that comes bundled is 1.6 Release 2. If I want to use a
different version of the Rhino engine (e.g. 1.6 Release 5), how do I
do that ?

b) In cases when I return a Javascript array from my script code, what
I get back in Java is sun.org.mozilla.javascript.internal.NativeArray,
which is probably a wrapper for org.mozilla.javascript.NativeArray. Is
it the common practice to handle these sun.org datatypes within my
Java program ? Or is there a way I can get back the actual mozilla
NativeArray type ?

Any help will be appreciated.

Thanks.
- Debasish

 

[Roedy Green]

a) With the current version of Java 6 distribution, the version of
Rhino that comes bundled is 1.6 Release 2. If I want to use a
different version of the Rhino engine (e.g. 1.6 Release 5), how do I
do that ?

I understand that Sun modified Rhino to fit their generic scripting
API. So that implies you can't simply plug in a different Rhino
version by swapping jars. Jet works with the original Mozilla Rhino,
so I gather all you need do is plop a different Rhino into the EXT
directory which will presumably have different package names and a
slightly different API.

see http://mindprod.com/jgloss/rhino.html

 

[Roedy Green]

b) In cases when I return a Javascript array from my script code, what
I get back in Java is sun.org.mozilla.javascript.internal.NativeArray,
which is probably a wrapper for org.mozilla.javascript.NativeArray. Is
it the common practice to handle these sun.org datatypes within my
Java program ? Or is there a way I can get back the actual mozilla
NativeArray type ?

What Sun is constantly trying to do with JCE, JDBC and now the
scripting is to make pluggable interfaces where various
implementations can replace Sun code with minimal fuss in the
applications. I laud them for this. Very early on I argued that
providing pluggable interfaces would be far more useful to the Java
community than providing polished implementations. I asked them to
create standard interfaces for every conceivable purpose, with a
reference implementation as a secondary concern, and a decent
implementation as a tertiary concern. I doubt it is because of my
request, but they have done what I wanted in spades. It is so rare a
corporation does what I wanted it to.

Sun are trying to mask the squirrelly differences between
implementation so you can swap implementors in a heartbeat. You are
trying to defeat them. You are better off ignoring Java's generifying
layer and using Mozilla Rhino directly.

see http://mindprod.com/jgloss/rhino.html

 

[debasish]

Sun are trying to mask the squirrelly differences between
implementation so you can swap implementors in a heartbeat. You are
trying to defeat them. You are better off ignoring Java's generifying
layer and using Mozilla Rhino directly.

seehttp://mindprod.com/jgloss/rhino.html

Thanks.
- Debasish

 

[Roedy Green]

Does this mean that if I want to stick to Sun's generifying layer,
I will be using classes like sun.org.mozilla.javascript.internal.NativeArray
for data type transformations between Javascript and Java ?
Or is there any other way of achieving the same goal.

Keep in mind, if you do that, you are cheating and defeating the
purpose of what Sun has done, so your code could break at any time.
Basically you get objects, find out their class with getClass, then
write code to cast them to specific objects so you can access the
native methods. You may find the methods you need in Sun's glue
objects are private to foil such attempts.

If I were you I would decide: do I want Sun generic scripting or
Rhino. Then, if Sun, stop cheating and use only the Sun API.. If
Rhino, bypass the Sun layer. Treat Rhino as if Sun had never heard of
it, downloading your own jar.

 

[debasish]

Keep in mind, if you do that, you are cheating and defeating the
purpose of what Sun has done, so your code could break at any time.
Basically you get objects, find out their class with getClass, then
write code to cast them to specific objects so you can access the
native methods. You may find the methods you need in Sun's glue
objects are private to foil such attempts.

Cheers.
- Debasish

 

[Tom Hawtin]

a) With the current version of Java 6 distribution, the version of
Rhino that comes bundled is 1.6 Release 2. If I want to use a
different version of the Rhino engine (e.g. 1.6 Release 5), how do I
do that ?

The java.net scripting project claims to have an R4 implementation.

https://scripting.dev.java.net/

b) In cases when I return a Javascript array from my script code, what
I get back in Java is sun.org.mozilla.javascript.internal.NativeArray,
which is probably a wrapper for org.mozilla.javascript.NativeArray. Is
it the common practice to handle these sun.org datatypes within my
Java program ? Or is there a way I can get back the actual mozilla
NativeArray type ?

The sun.org.* classes are org.* classes simply renamed. This allows you
to actually use your own version of Rhino directly. Otherwise it's be
like trying to use your own copy of java.lang.String, which simply
doesn't work. sun.* is special in that untrusted code cannot access it.

A better approach would be to create a Java array (or other Java object)
from the JavaScript. Then you could use any scripting API implementation
of JavaScript.

Tom Hawtin