javac code generator based java source interpreter, then... genuine scripted Java language

[Compl Yue Still]

Hi there,

I'm recently working on an open source piece that will open scripting
access to running applications in a server JVM, through SSH (with
publickey authentication). It's maining concerning monitoring and
management of thte server application over client/server connectivity.

I've just done with the server side SSH part, and started the *Java
Shell* support. I had been planning www.BeanShell.org for this, but
get quite unhappy about that it hasn't get to support Generics / var
args and etc yet. Coz what I got to support is a new object database
system makes heavy use of these new features. And after some
investigation I found several other *Scripting Java* products neither
get this well.

The result I'm expecting is that a Java application administrator or
developer can interactively type and execute Java statements against
his running application environment, with a text terminal remotely
connected through SSH. No extra management tools should be needed for
this because he is just typing *RAW* *NATIVE* Java statements as
*scripts* into the server JVM, and most ideally he should be able to
copy & paste his *scripts* into java source files of his static
project without modification. This should increase his productivity
and best help new comers to existing Java applications or base
environments.

However since all current *Java Scripting* tools fall far behind the
evolution of Java, that lacks new but heavily used (by emerging
applications) language features, I put thoughts about leveraging AST
from javac or ecj to produce an up-to-date Java Interpreter that can
*execute* Java statements in most recent syntax.  After thoughts and
some investigation, I have come to a rough idea that we can just copy
code generator in current javac and refactor it to *perform* the
bytecodes instead of to *generate* and *store* them to classfile
format.

Since resolving functions are already their for the attribution phase,
the core task for such an interpreter seems to be a virtual
*Callstack* that not only calculates space requirements but also
actually stores objects and values. I (roughly) think this will be
enough for a single-threaded interpreter that doesn't support
constructing anonymous class instances to pass to compiled class
methods.

So what do you people think about this? Is it possible and practically
viable from your views?

Thanks & Regards,
Compl