> From: news [mailto:[EMAIL PROTECTED]]On Behalf Of Galen Boyer
> Sent: Friday, December 06, 2002 8:45 AM
> To: [EMAIL PROTECTED]
> Subject: Re: BanInfo wizard anyone?
>
>
> On Fri, 6 Dec 2002, [EMAIL PROTECTED] wrote:
> > Another idea would be to add options to the jde-jeval
> > function or new commands to
> >
> > * evaluate a bsh expression (e.g., a script invocation)
> > and insert the result in a new Java source buffer
> >
> > * evaluate a bsh expression and insert the result at
> > point in the current buffer
> >
> > This would make it easey for users who are not proficient
> > in Lisp to use BeanShell scripts (i.e., Java) to
> > generate Java source code inside Emacs.
>
> Maybe there could be a translation layer from beanshell/java to
> elisp? If this were in place, the call for java help from the
> non-elisp guy could go something like, you could present a java
> interface that you would like implemented by someone. They could
> run off and code java and hand back their code. Your interface
> could then run through your beanshell-to-elisp translation layer
> and the elisp guys could make it happen in Emacs.
>
> The translation layer could handle things like the java method
> signature returning, say, a hashmap. The layer could have a
> hashmap to alist converter.
I've actually got a working prototype of a generic interface/translation
layer that does just that. For now, I'm calling it JUCI (JDEE Universal
Communication Interface). It allows elisp to call java and java to call
back to elisp in a standard manner. It's still very alpha. One (minor,
IMHO) drawback is that it requires JDK 1.3 or greater, because I'm
making use of the java.lang.reflect.Proxy mechanism.
My plan in the near term is to use it to try to integrate Transmogrify,
which requires that the editor implement a 'Hook' interface for getting
info like the current position of the cursor, list of files in the
project, etc.
Calling java from elisp is straightforward; you create a java interface
containing the methods you wish to call from elisp and an implementation
of that interface that has a default constructor:
public interface MyHelper {
Object doSomething(Object arg);
}
public class MyHelperImpl implements MyHelper {
public MyHelperImpl() {}
public Object doSomething(Object arg) {
// ...
}
}
On the elisp side, all you would need to do is declare a defun like
this:
(defun my-helper-do-something (arg)
(jde-juci-invoke-java "MyHelperImpl" "doSomething"))
For java code that calls elisp, you declare just an interface. On the
elisp side, you implement that interface by creating a defun with a name
following certain conventions and a matching arglist:
public interface MyPrompt {
String getUserInput();
}
(defun my-prompt-get-user-input ()
(read-from-minibuffer "Input: "))
// java code that invokes elisp
Prompt prompt = (Prompt)
jde.juci.ConnectionFactory.getConnection(MyPrompt.class);
String result = promt.getUserInput();
This will cause emacs to enter the minibuffer, capture the user-entered
string, and return it to the java code.
My hope is that the JDEE community will find this approach useful and
that I can find enough time to clean up the code, document it and make
it robust. I'd appreciate any feedback.
> Then, also, there could be cool things like Elisp debugging
> switching to java debugging when the debugger hits the
> translation layer.
Whoa, there. Cool idea, but more than I can digest right now :)
/Nick
