Hi Paul,
[snip]
> The jde-jeval function already provides all the functionality required
> for two-way communication between the JDEE and an external Java
> application. I explained how this works in a previous post.
Paul,
jde-jeval provides all the functionality required for two-way communication - assuming that:
1) the Java tool was written with Emacs interaction in mind, since in order to do Java->elisp actions
the tool has to return proper elisp code for evaluation.
2) The flow control is completely under the control of the elisp side.
These two assumptions are not always the case for many good tools out there.
Nonetheless these tools are useful enough to make their integration to JDEE a worthwhile goal.
Take a refactoring tool like Transmogrify as an example.
First, it was designed as a plug-in for a generic Java editor, and Emacs-JDEE currently don't qualify as such.
Case in point, Transmogrify don't return elisp code for evaluation to affect the environment.
Second, once a refactoring is started (in the JDEE case, by a jde-eval call to the associated Java method)
the tool takes control of the flow control, making calls back to the editor environment based on internal
decisions. For example, it may query the contents of the region, and based on analysis of that content ask
the editor to change point. This is a much more complex iteration model than the one supported by jde-jeval.
> The only thing that Nascif is proposing to add is
> a Java wrapper around Lisp code required for the Java application
> to manipulate Emacs.
From the discussion above, you can see that this wrapper is much more than that.
It allows JDEE to be extended with Java tools that know nothing about Emacs or Elisp,
and is much more flexible in its assumptions of the flow control.
> I think the jde-jeval approach of having
> the Java process simply return Lisp code is superior because it
> allows the Java process to have access to the full range of
> Emacs functionality.
True, but at a big price; to use this approach a Java tool has to be written (or re-written) to fit into
the jde-jeval model. I won't argue that it is better for tools created from scratch to be integrated with
Emacs by a Java/Lisp programmer; but I don't think it is sufficient to support already existing tools,
nor tools created by designers that are not proficient in elisp.
> With Nascif's approach, only the functionality
> exposed by the wrapper code is available to the Java process.
True, but then again, plug-ins typically are designed with access to a very small and well-defined
API to the environment (the editor) in mind. With a dozen methods exposed (get/set region,
get/set point, load buffer, etc.) we would be able to support a very broad range of Java plug-ins.
We could always expose a Lisp "pass-through", to allow the Java tool to send elisp code back.
In this way the Java wrapper would be a superset of the jde-jeval approach.
> As for avoiding learning Lisp, I think people who want to write Java
> extensions to Emacs are better off putting their effort in learning
> elisp than in learning a Java wrapper around elisp.
Paul, what about people that want to write a Java plug-in for *any* editor? In that sense
JDEE/Emacs is too far away from the other IDEs out there. Not better or worse, but different.
True, there is no "standard" for plug-ins at this point, but the ones already available (from NetBeans,
JEdit, JBuilder, just to name a few) don't rely on elisp...
Not to mention the plug-ins and tools that have already been written. Is it a good position to simply
ignore them, or to have to rewrite them from scratch?
I think JDEE would greatly benefit by providing a true Java-based plug-in architecture and
removing the elisp "language barrier". What is the problem of offering a more generic
and easy to use way for Java designers to extend JDEE? Nothing against learning elisp,
but code re-use and standardization are worthwhile design goals as well. They may take away some flexibility,
but the payback is great - more people will be adding extensions because of the reduced barriers.
Best Regards,
Nascif
