Adding lightweight scripting

[Timo Kinnunen]

I'm evaluating ways to add scripting capabilities to my Java
applications. I'm targeting J2ME and J2SE, which means I don't have
class loaders or reflection. So, BeanShell is out.

I'm leaning towards compiled scripts in hope of better performance.
My current idea is to implement enough of a JVM to load a single Java
class and run static methods with primitive data.

So, the question. From a performance point of view, is a stack based
abstract machine ideal or should I look for something register based?
Or is there something even better? What about the language to be
compiled, shuold I use Java or something else?

The abstract machine will be running in Java, so I'm free to
implement anything, well, almost.

Or, have I brushed off interpreted languages too fast? Would the
higher level of a serialized evaluation tree beat the pants off of
lower level compiled code?

 

[xarax]

I'm evaluating ways to add scripting capabilities to my Java
applications. I'm targeting J2ME and J2SE, which means I don't have
class loaders or reflection. So, BeanShell is out.

I'm leaning towards compiled scripts in hope of better performance.
My current idea is to implement enough of a JVM to load a single Java
class and run static methods with primitive data.

So, the question. From a performance point of view, is a stack based
abstract machine ideal or should I look for something register based?
Or is there something even better? What about the language to be
compiled, shuold I use Java or something else?

The abstract machine will be running in Java, so I'm free to
implement anything, well, almost.

Or, have I brushed off interpreted languages too fast? Would the
higher level of a serialized evaluation tree beat the pants off of
lower level compiled code?

Interpreted languages that you control are very
convenient and flexible. Also consider pseudo-compiled
languages that are compiled or tokenized into action
elements that you can plug into a state machine.

I am facing a similar challenge for adding a scripting
language to my Java application that will let the user
programmatically drive my application, respond to events,
etc. Currently the user must point-and-click, and use
his brain to discern significant events and how to
react to those events (by more pointing-and-clicking).

Fortunately, my application internals use Java interfaces
for making things happen and for reporting events. These
interface semantics will be represented in the scripting
language as command keywords or event actions. The script
driver will likely be a separate thread that listens for
events from the interfaces and drives the appropriate
script for that event. Likewise for commands, the thread
will take the parameters from the script and poke the
appropriate action interface with those parameters.

The rest is just simple stuff like parsing numbers,
strings, arithmetic operators, calling other scripts,
etc. You will need to design a stackframe that can
hold script variables and parameters. Of course, since
you are doing all of this in Java, it will be easy to
design everything as interfaces and classes, and use
some of the built-in facilities for pattern matching,
string tokenizing, etc.

Do not try to get too fancy at the start. Just try
to design a simple parsable language that can recognize
simple variable declarations, simple arithmetic and
comparisons, and simple conditional expressions
(if-then-else). Then move on to loop control. Then move
on to stackframes and calling other scripts with parameters
and returning a result to the caller. Finally, add support
for command keywords and event keywords, so that the script
can "talk" to your application and get answers back.

When you have all of that working, then you get to
design and build a script editor and debugger, so that
user can write and test his scripts under the control
of your application and your built-in editor/debugger.


Good luck.


--
----------------------------
Jeffrey D. Smith
Farsight Systems Corporation
24 BURLINGTON DRIVE
LONGMONT, CO 80501-6906
http://www.farsight-systems.com
z/Debug debugs your Systems/C programs running on IBM z/OS!
Are ISV upgrade fees too high? Check our custom product development!

 

[Harald Kirsch]

I'm evaluating ways to add scripting capabilities to my Java
applications. I'm targeting J2ME and J2SE, which means I don't have
class loaders or reflection. So, BeanShell is out.

Did you have a look at jython (www.jython.org) or jacl
(http://www.tcl.tk/software/java/) which are java implementations of
python and tcl? Or does your mention of "no class loader" preclude
them alltogether?

I would guess that you could at least use Jacl's interpreter somehow,
which would give you the parsing of the script and certainly ways to
jump into your application specific classes.

Harald.

 

[Timo Kinnunen]

Did you have a look at jython (www.jython.org) or jacl
(http://www.tcl.tk/software/java/) which are java implementations
of python and tcl? Or does your mention of "no class loader"
preclude them alltogether?

Jython seems to be out alltogether.

I would guess that you could at least use Jacl's interpreter
somehow, which would give you the parsing of the script and
certainly ways to jump into your application specific classes.

Jacl's approach certainly makes plugging in my APIs easy.

I think there will be two contexts in which the scripts will be
executed. First, in an inner-loop running simple state machines or
logic decisions, and second, setting up UI and loading and saving
program's state. The priorities are thus performance and easy of
development, respectively.

To reiterate, the options that I've looked at are:

1. Create a VM (JVM) to execute byte code in a loop on a stack.
Pros:
* Fully defined funtionality
* Fully defined byte format
* Several existing compilers
* Should satisfy my performance requirements when execution stays in
the VM
Cons:
* Have to translate arguments when going from my code to script and
vice versa
* Have to create adapters for my classes for them to be usable in the
scripts

2. Create a hierarchy of high-level commands/actions, which are
evaluated as a tree
Pros:
* Creating new actions is easy
* No translation is necessary (cast'n'call)
* If based on Java, no adaptors are needed
Cons:
* No existing byteformat or compiler (?)
* Have to choose language
* Arithmetic expressions involve lots of method calls

I'd like to get the best of both worlds, but I don't see how.

 

[Timo Kinnunen]

Interpreted languages that you control are very
convenient and flexible. Also consider pseudo-compiled
languages that are compiled or tokenized into action
elements that you can plug into a state machine.

Thanks for your response.

I'd like to do as much of the work up-front, so the further I can
compile things the better. I'd also like to reuse any existing
compilers, binary formats and specifications rather than rolling my
own. Please see my reply to Harald Kirsh, where I've summed my
thinking in a more concise format.