JSR223 improvements ("Scripting for the Java Platform")

[Iris Clark]

Hi, Jason.

Perhaps you should investigate Project Nashorn [1]?

iris

[1]: http://openjdk.java.net/projects/nashorn/

-----Original Message-----
From: Jason Sachs [mailto:jmsachs at gmail.com] 
Sent: Wednesday, December 19, 2012 11:51 AM
To: web-discuss at openjdk.java.net
Subject: JSR223 improvements ("Scripting for the Java Platform")

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