JSR223 improvements ("Scripting for the Java Platform")

[Jason Sachs]

Where's the right place to get a discussion going on potential
improvements to JSR223?

I posted a message to the dev at scripting.java.net mailing list last
year (http://java.net/projects/scripting/lists/dev/archive/2011-05/message/0
-- quoted below) but got no response, and now that I've finally got my
head above water with my free time, I'd like to bring up the subject
again.

--Jason


---------- Forwarded message ----------
From: Jason Sachs <jmsachs at gmail.com>
Date: Fri, May 6, 2011 at 2:57 PM
Subject: improvements to JSR223?
To: dev at scripting.java.net


I'm not familiar with the JSR process, but of the many Java APIs out
there, javax.script.* seems to be one of the more lacking APIs given
its potential usefulness.

Are there any efforts afoot to improve it? If not, what would it take?

There are a number of what seem like missing features to me, things like:

- (1) support for interactive scripting
-- (1a): UI shell support -- there's very little, if anything, out
there to facilitate a GUI text console for interacting with a script
engine
-- (1b): As-you-go interpretation/multiline statements -- Dealing with
lines of a script that arrive in slow sequence and may comprise a
multi-line statement is a PAIN. I ended up doing this for Rhino and
Jython by running a compile each time a new line comes in, and if a
syntax error is detected at the very last character, I assume it's a
multiline statement in progress (vs. a syntax error in the middle,
which is a definite error). This works but errors in the script get
the line # wrong, as each statement starts from line 1.
- (2) interfaces to improve coupling between Java and script code
-- (2a): support for array/map/function data structures -- If you call
a Java method from JSR223 Rhino with an argument of {a:1, b:2, c:3},
the Java method sees a
sun.org.mozilla.javascript.internal.NativeObject. Javascript arrays
give you sun.org.mozilla.javascript.internal.NativeArray, and
functions give you
sun.org.mozilla.javascript.internal.InterpretedFunction. None of them
can be manipulated from within Java without using sun.* classes. If
there were well-defined interfaces for arrays/maps/functions, then not
only could Java code manipulate the data received from Javascript, but
Java code could expose data to Javascript with a much simpler syntax,
e.g. x[0] = 123 and x.abc = 456 rather than x.set(0,123) and
x.put("abc", 456). Replace "Javascript" with your favorite scripting
language in this case. Arguably, Rhino could have been implemented to
use List<T> and Map<K,V> in their NativeArray and NativeObject
implementations, but a good scripting interface should state this
explicitly.
-- (2b): support for coupling java.lang.Iterable with a language's
native iteration technique -- also something that could be handled
well in a scripting language
-- (2c): something like ScriptableObject that's a little bit leaner +
more general to languages.

--Jason