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

[Jonathan Gibbons]

Compl,

With respect, this alias is for discussion of issues related to the  
development of the javac compiler, and related tools in the OpenJDK  
source base.  Your news is interesting, but somewhat off-topic.

-- Jonathan Gibbons



On Jul 11, 2007, at 8:07 AM, Compl Yue Still wrote:

> Hello,
>
> I have finished the part with Java Compiler API support, which is
> suggested by Peter, it seems work quite fine. I'm very happy that
> javac compiles really fast!!
>
> I have requested this piece of work as a dev.java.net project at:
> http://sjsh.dev.java.net it is pending approval now but if any of you
> can access its files, I packed the latest src under Document and
> Files/src-release. It is BSD licensed and I hope everyone enjoy it.
>
> Trying it out is quite easy, there's a pre-built sjsh.jar, just run
>
>  java -jar sjsh.jar
>
> and it will start output some info, an authorized private key will be
> automatically generated. then run in another terminal:
>
>  chmod 600 SJSH-Root/home/sjsh/.ssh/id_rsa
>  ssh -l sjsh -p 22022 -i SJSH-Root/home/sjsh/.ssh/id_rsa
>
> if you have OpenSSH client installed. or you may need to convert
> id_rsa to your favorite SSH client's format and use it to login.
> After accept the host key and logged in, the terminal should display
> something like:
>
> This is an interactive Java(TM) shell, type in Java(TM)
> statements to get them executed.
>
> Type in Ctrl^D to logout.
>
> Type in ? or help for a list of available commands.
>
> Type in <Tab> to complete commands.
>
> Use ¡ü ¡ý arrow keys for command history.
>
> SecueJSH Java(TM) Compiler Ready.
>
> [jsh ]$ ?
> Built-in commands:
>
> class <class-name> +<class-code>
>   Start defining a new class in current package
> def <field-name> [ <type> [<comment> | -] | - ]
>   Define a field that persists across statements
> feedback [ on | off ]
>   Control display of feedbacks
> fields
>   Show all fields currently defined
> import <package-name>.* | static <qualified-class-name>.*
>   Add an import
> imports
>   Show all imports in current import list
> lineNo [ on | off ]
>   Control display of line numbers
> package [ <package-name> ]
>   Specify current package
> preview [ on | off ]
>   Control display of previews
> redef <field-name> [ <type> [<comment> | -] | - ]
>   Redefine a field that persists across statements
> undef <field-name>
>   Undefine an existing field
> unimport <existing-import> | *
>   Remove specified import
>
> Type in:   help|? <cmd-name> [<topic>]
> for more details of a built-in command.
>
> [jsh ]$
>
> Try some interactive java and, have fun ;-)
>
> cheers,
> Compl
>
> On 7/6/07, Compl Yue Still <complystill at gmail.com> wrote:
>> Hi Peter,
>>
>> Thanks for the quick and informative reply, I didn't get to this
>> example before, and it seems very promising.
>>
>> But my concern is still about interactivly executing Java statements,
>> like scrirpts, idealy like in a Shell (with word completion etc.),
>> This is why I'd been considering BeanShell at the beginning.
>>
>> I havn't walked close enough to the Java Compiler API based approach
>> so far, mainly in worries about Java class loading. I often heard JSP
>> containers run OutOfMemory with default size for perm gen of heap,
>> while the main heap is still free, simply because frequently
>> recompiling of JSP pages i.e. class loading.
>>
>> I quite like the example you showed here, since it will just do
>> EXACTLY what an state-of-the-art JVM does, but I'm still afraid of
>> such an implementation within a long-run app-server JVM will cause
>> problems sooner or later. I'm expecting positive opinions from you
>> regarding your expertise in all these around.
>>
>> And another issue with this approache come to me that to prompt user
>> inputs from an interactive shell, where complex constructs beyond
>> simple expressions should be allowed, like for() loops etc. An AST
>> parser knows well whether it has received enough input as to  
>> construct
>> an evaluable node, but how could my code deal with that when it's not
>> doing parsing jobs? One single line expression a time is not enough
>> for it to be really useful.
>>
>> Best Regards,
>> Compl
>>
>> On 7/6/07, Peter Ahé <peter at ahe.dk> wrote:
>> > I don't understand why you want to interpret, the JVM is good at  
>> that.
>> >  Consider using the approach of this demo which compiles and  
>> evaluates
>> > Java expressions:
>> >
>> > https://ksl.dev.java.net/source/browse/ksl/trunk/compiler/test/ 
>> tools/javac/api/evalexpr/
>> >
>> > Cheers,
>> > Peter
>> >
>>