379385 - Document Rhino mapping for Java SE6's javax.script package

Status: RESOLVED INACTIVE

(Rhino Graveyard :: Core, defect)

Description

[Norris Boyd]

Rhino is currently embedded by Sun into JDK 1.6 (see "Scripting for the Java Platform" at http://java.sun.com/javase/6/docs/technotes/guides/scripting/index.html). 

But the version used by Sun is an older Rhino version, is less feature rich (no compilation to classes or E4X), and there is no access to Rhino APIs. The solution is to write the necessary glue code and configuration to make Rhino loadable through javax.script, but still accessible through the existing APIs. This is useful for people who start off using the existing small Rhino implementation in JDK6 and then decide they need more.

Comment 1

[Attila Szegedi]

To be honest, I have started implementing this last September, but figured out eventually that the same people (mostly A. Sundararajan) who wrote the JSR-223 adapters for JDK 1.6 also provided adapters for lots of other languages as well, among them the the adapter for our mainline Rhino, at 

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

You can browse the source quickly at 

<https://scripting.dev.java.net/source/browse/scripting/engines/javascript/src/com/sun/phobos/script/javascript/>

I decided to leave it at that for now, since their implementation is mostly identical to what's in JDK, so it behaves in a completely compatible way, meaning people can really just put our Rhino build in the classpath, plus the Rhino JSR-223 adapter classes from the above mentioned site, and have it "just work". If we undertook a completely independent implementation, it'd probably have at least slight implementation incompatibilities. I.e. Sun's current implementation exposes the JSR-223 ScriptContext object used for a particular evaluation as "context" top-level variable. They provide a "sync" global function to act as a synchronized keyword in Java, i.e. you use it as "sync(lock, someFunction)" to execute someFunction (most likely an anonymous in-place defined) synchronizing on a lock object. And there's even more implementation-specific quirks.

OTOH, the current code that's in there still disables E4X, and doesn't use ContextFactory (or better said, only uses the global static ContextFactory via Context.enter()/Context.exit()). On the plus side, they at least allow compiled execution, although you need to set a JVM-level system property "com.sun.phobos.javascript.useInterpreter" to "false" to enable it; not terribly configurable especially if you have two isolated thingies in your JVM (i.e. two webapps in a servlet container) that want to use it with different settings...

If there's an agreement that we want our own implementation, I'd be happy to finish what I started last September, and we can discuss the exact feature set we want in there.

Comment 2

[Norris Boyd]

This is great--I didn't realize that these mappings already existed. 

I'll leave this bug open and change the title from "Create Rhino mapping for Java SE6's javax.script package" to "Document Rhino mapping for Java SE6's javax.script package"--we should at least reference the above site in the docs so others can find this binding.

Comment 3

[Hannes Wallnoefer]

I'm glad I found this bug - I was just about to open a new one, and start implementing those javax.script classes. 

My motivation is actually slightly different, a long-standing bug with OpenJDK on Ubuntu and (probably most) other Linux distributions: https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/255149

The problem is that the OpenJDK/Icedtea folks just changed Sun's Rhino scripting engine to use the original rhino class names (from Sun's repackaged sun.org.mozilla.javascript.internal Version) and rely on the rhino jar to be on the boot classpath, which prevents anybody from using their own version of rhino except by resorting to the -Xbootclasspath option, or removing the symbolic link that puts the bundled rhino in the boot classpath.

My proposal is to bundle the script engine implementation with rhino (see my comments here: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=179#c2). For OpenJDK, this means they can load the rhino script engine _and_ implementation through the same custom classloader and from the same jar file, and for all other users it means they can use a newer version of rhino simply by changing the script engine name to "rhino-nonjdk".

And since the scripting.dev.java.net project is BSD licensed, it shouldn't be a problem to use those classes: https://scripting.dev.java.net/source/browse/scripting/engines/javascript/LICENSE.TXT?view=markup

Norris, Attila, what do you think?

Comment 4

[Norris Boyd]

Sounds great! Thanks for investigating.

Comment 5

[Hannes Wallnoefer]

Attachment: Patch adding the rhino engine from scripting.dev.java.net

This patch addes the latest CVS version from scripting.dev.java.net to using org.mozilla.javascript.scriptengine[.util] as package names. It seems to work well, but when I run jrunscript asking for the "javascript" or "rhino" engine, it randomly gives me the bundled JDK or standalone version of Rhino, which is weird.

jrunscript -cp build/rhino1_7R3pre/js.jar -l javascript

Comment 6

[Sylvestre Ledru [:Sylvestre]]

Closing. Bug management is now done here:
https://github.com/mozilla/rhino