Define a shared model between the JVM and JavaScript

[mslinn]

Oracle Nashorn can share data and code between the JVM and JavaScript, so JVM libraries can be called from JavaScript, and vice-versa. That gives a lot of flexibility.

Engine Name      = Oracle Nashorn
Engine Version   = 1.8.0_151
Language Name    = ECMAScript
Language Version = ECMA - 262 Edition 5.1
Names = nashorn, Nashorn, js, JS, JavaScript, javascript, ECMAScript, ecmascript

Oracle's Nashorn docs are extensive, and the User Guide includes API docs.

It is possible that other scripting engines might be better than Nashorn, or might be good to have in addition to that JavaScript engine. It is easy to create shells that are similar to the JavaScriptShell/JavaScriptEvaluator that has already been created. Provided that a user-friendly way to specify which shell is desired, dozens or hundreds of shells and their interpreters could be run concurrently by the present design.

• OpenJDK Panama
• Native Script Engine or Go Panama with Jim Laskey
• Ringo
• TheConsole

Even if there is only one process on the JVM that needs to communicate with one process on a scripting engine, there is the possibility that each process might attempt to alter the same value at the same time. Thus concurrent Maps must be used. Expressed in Scala, both sides conceptually need an interface something like:

import scala.collection.concurrent

case class beth(data: concurrent.Map) {
    def status: concurrent.Map
}

Oracle Java's Nashorn JavaScript engine has been wrapped in an Evaluator subclass called JavaScriptEvaluator, which is mediated by a Shell subclass called JavaScriptShell. Other Shells, each with their own Evaluator, exist.

From the point of view of a Java or Scala program running on the JVM, and a JavaScript program's point of view running on a JavaScript engine, the namespace provided by an Evaluator should seem a little bit like a transparent mirror, with the same namespace names on both sides of the mirror. The mirror has some inherent distortion, in part because JavaScript only supports Double; it lacks Int and Float. Other limitations will no doubt become apparent, and they should be documented in the this project's wiki as they are discovered.

The current version of the JavaScriptEvaluator always returns results as type AnyRef. There may be some way that we can provided some support of typed responses in the future.

With Java/JavaScript inter-operation, library code in one Shellcould be invoked from JavaScript, Java and Scala. Also, custom Java and Scala code could leverage existing JavaScript such as Node.js libraries. We need unit tests for all these scenarios.

It is important that the simplest possible implementation be developed. This often takes 3 quick iterations, with most of the original code replaced at least once.