Nascif Abousalh-Neto writes: [snip]
> 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? Finding somebody willing to do the work to make it happen. There is an approach to interfacing external tools, that Eric Ludlam has proposed, that is worth considering. Eric's suggestion is to create an interface consisting of eieio classes on the Emacs side and Java proxy classes on the Java side. In other words, every eieio class on the Emacs side would have a Java proxy class on the Java side. A socket-based interface would keep the counterpart classes synchronized, e.g., updating a field in eieio class A would cause the interface to update the equivalent field in the Java proxy class A, and invoking a method in a proxy class would invoke the corresponding method in the eieio class. The proxy class system would inclde a code generator that would generate Java proxy classes automatically from eieio classes. Thus, you might write an eieio java-source-file class with methods for opening and closing the Java source file that the class represents. You would then run the code generator to generate the Java proxy class, JavaSourceFile, with the appropriate methods. You could then include the proxy JavaSourceFile class in your tool interface. Now whenever your tool interface wants to open a Java source file, it invokes the open() method of the proxy class. The proxy open method invokes the equivalent open method of the eieio java-source-file class. The advantage of this approach is that it reduces developing interfaces to external Java processes to writing eieio classes. The interface developer doesn't have to write any Java code or interprocess communications. This doesn't really help the elisp illiterate plugin tool developer, but it would make it easy to create and maintain a plugin interface for the JDEE. - Paul
