> -----Original Message-----
> From: Paul Kinnucan [mailto:[EMAIL PROTECTED]]
> Matt Munz writes:
> > Nascif,
> >
> > I have been curious about the BeanShell since I heard
> about it, but haven't
> > tried it yet. It sounds like you're familiar with it.
> >
> > Nacif> It is easy to have a Lisp function calling a Java
> method, using the
> > BeanShell; not so much to do the reverse.
> >
> > Is this really true? It seems to me that your BeanShell
> app can spit out
> > arbitrary lisp code as a text stream that could be
> dynamically loaded in
> > emacs. Can you elaborate on what specifically makes it
> difficult to do 2-way
> > interactions with BeanShell apps?
> >
>
> This is what JDE beanshell apps do now. The JDE Lisp function
> bsh-eval-r
> accepts an arbitrary string of Java code as an argument, e.g.,
> invocation of a static method defined by a JDE app, and sends it
> to the Beanshell's standard input. It then suspends Emacs until it
> receives a response from the Beanshell. bsh-eval-r assumes that
> the response is a Lisp form. When it receives the Lisp form,
> bsh-eval-r
> evaluates it.
Although this approach is incredibly powerful, it is not generic enough. It allows an Elisp app to call a Java app, and allows that Java app to return an elisp expression for evaluation (thus affecting the JDE environment). But it does not allow the Java application to see the results of that evaluation; the elisp side of the logic would have to make an addittional call to pass back that result.
It also does not address (as Paul said before) asynchronous calls. For example, what if you're trying to interface to a Java library that uses listeners/events? That goes from networks protocol libraries (packet received) to GUIs (button pushed). Also, it does not address already existing code that expects to have control of the information flux, making calls to the external "container" to obtain information when needed.
To solve these problems you would need a true two-way communication path, meaning that somehow you would need Emacs to "listen" for and respond to commands from the Java side. I understand and agree with the statements that a framework like that would be really complex to implement due to the interprocess communication issues. On the other hand, the benefits are great: just look at the amount of plug-ins already written for the JBuilder Open Tools API (not to mention what is also being done for Eclipse, NetBeans, Elixir, JEdit, etc.):
http://www.kylecordes.com/jbot/
http://www.borland.com/jbuilder/resources/jbopentools.html
http://jbopentools.sourceforge.net/
Granted, some (maybe most) of these tools could also be ported to JDE/Emacs using plain elisp/BeanShell. But it would still require a lot of duplicated "glue" code that could be formalized (as Sandip suggested) to make it easier for non-Lisp programmers.
Even if we forget about two-way communication capabilities for a while, having a more framework-oriented standard for adding Java extensions to JDE would be highly beneficial. JDE could have an "/extensions" directory where it would search for extension jar files. They would be automatically loaded at BeanShell start-up time, and appropriate menu entries/elisp wrappers would be generated using Java Reflection or a config file. When activating the extension code in response to a user command, JDE would pass to it the current environment info (file name, cursor position, text in the active region) - if two-way communication is implemented, an API would be provided to allow the Java code to ask for this information directly.
There is a lot of cool stuff out there - code beautifiers, UML browsers, refactoring tools, lint tools, network protocol stacks - that could be integrated to JDE by regular Java developers *today* if only they had a framework like that. The challenge is big but so are the benefits...
Regards (and sorry for yet another lengthy e-mail)
Nascif
>
> - Paul
>
>
>
