Re: JDEE plugins
I wonder if there's a place in here for kawa (http://www.gnu.org/software/kawa/). It would be ideal for java-elisp communication, since it's a scheme environment that runs in Java. It even has an elisp mode! Galen Boyer [EMAIL PROTECTED] writes: On Tue, 18 Feb 2003, [EMAIL PROTECTED] wrote: Sounds like a great idea! I would volunteer to re-write the Jalopy (http://jalopy.sourceforge.net/) integration package I put together. I could also take a stab at a re-write for the integration package for PMD (http://pmd.sourceforge.net/). Those Elisp-Java packages have an awful lot of code in common, and it would be really nice to create a standard way to create them - specially the bit about a standard way to integrate with the BeanShell. I would like to suggest also a standard way for those packages to present their output. A lot of them generate warnings or errors that go very well in a compilation mode buffer. I think this behavior can be abstracted as well. Maybe the beanshell could be viewed as an application server. Let me work through my thoughts. Would it make sense that java code that is executed through the beanshell not have to println(someElispString); but instead, any java code that is to be executed by the beanshell and subsequently eval'd into elisp, return a java datatypes transformable to elisp set of objects, like hashmap, array, ... Then, the beanshell could offer a set of classes which take these particular return objects and transform them into println's of elisp strings to be eval'd by elisp. The only part that doesn't seem clear to me is how to have elisp not have to understand the java code, its structure and exact names as well as its exact syntax. I'm thinking, first an eieio interface to elisp be required to be implemented by the elisp code of the package. A mapping layer, maybe xml, or just elisp list, be used to wire elisp class/method names to java class/methods. Then, the elisp package integrates with a particular elisp interface and the java code integrates with a particular java interface and the elisp to java is the black box that none of the two sides of code knows about, taken care of by the beanshell's black box. This would also allow java requirements for some particular need of the JDEE to be given to a willing java coder and the elisp requirements given to a willing elisp coder and the two sides actually code in their respective VMs without having to hook the two, fairly incompatible VMs up during development. Of course, what I'm thinking is that a JDE user could integrate some jakarta package by working with Paul on the java interface needing to be implemented. Paul or another of the elisp studs, then codes up the elisp side of the house waiting for the java coder to finish his work. Then, elisp becomes a client and the java code becomes the middleware implementing interfaces the beanshell application server will be executing. -- Galen Boyer
RE: JDEE plugins (was JUCI)
Hi, Just my two cents, I'm a lisp-wimp as I am sure are many of the users of JDEE, but a good Java programmer. If there was some way that I could write JDEE extensions in Java for at least some subset of plug-in functionality that would be great since I never seem to find the time to really learn lisp. I realize it might be too much to accommodate us lisp-wimps, but just keep it in mind if it turns out to be not such a big deal to go in this direction. Cheers, Mark -Original Message- From: Paul Kinnucan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 18, 2003 5:25 PM To: Nascif Abousalh-Neto Cc: Paul Kinnucan; [EMAIL PROTECTED] Subject: RE: JDEE plugins (was JUCI) Nascif Abousalh-Neto writes: Sounds like a great idea! I would volunteer to re-write the Jalopy (http://jalopy.sourceforge.net/) integration package I put together. I could also take a stab at a re-write for the integration package for PMD (http://pmd.sourceforge.net/). Those Elisp-Java packages have an awful lot of code in common, and it would be really nice to create a standard way to create them - specially the bit about a standard way to integrate with the BeanShell. Great. I assume that you will conform to the directory structure that I proposed and provide the package as a jar or lisp file. Please let me know if you intend to implement any other suggestions, e.g., Ole's idea of a standard entry point: lisp/plugin.el I would like to suggest also a standard way for those packages to present their output. A lot of them generate warnings or errors that go very well in a compilation mode buffer. I think this behavior can be abstracted as well. beanshell.el previously contained an unfinished eieio class that provides a compilation-style buffer for BeanShell-based applications. My idea is that the compile server and the ant package and any other Beanshell based applications that needed compilation-like buffers could specialize and instantiate this class. I deleted it in my last update but I think I'll revive it. - Paul Regards, Nascif -Original Message- From: Paul Kinnucan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 18, 2003 3:27 PM To: [EMAIL PROTECTED] Subject: JDEE plugins (was JUCI) Hi Nick, I am posting my response to your idea of JUCI-based plugins to the JDEE list because I am interestedin getting other people's input on this idea. - Paul Nick Sieger writes: [snip] Do you have a long-term vision for any standard interface or API for integrating user-developed components? Right now, most of the user-submitted code seems to be little snippets here and there. It would be cool if people could share pieces of code in a manner that they could just drop a file or a jar archive in a well-known place in the JDEE installation filesystem and the JDEE would auto-detect the new component, load it up and make the code available. I haven't really thought about it. One thing that occurs to me is that I could add a subdirectory called plugins to the JDEE tree where users could put an entire hybrid Java/Lisp plugin, i.e., the JDEE tree would look like this: JDEEroot lisp java doc plugins plugin1 lisp java scripts classes src lib doc javadoc design help info html src plugin2 ... The JDEE would load/eval the files in the lisp directory and add the classes directory and the jar files in the lib directory to the BeanShell's classpath. I could also add a Plugins submenu to the JDEE menu and define a JDEE Lisp function that plugins could call to add a command or submenu of commands to the Plugins directory. This solution is not as convenient as your idea of a single jar file. But remember that one of the principles of freeware is to include the source. Perhaps the first time the JDEE detects a jar or zip file at the top level of the Plugins directory it could unpack it, assuming that its contents are structured as I proposed. This would provide the ease of distribution and installation that you have in mind with my objective of ensuring that plugins are complete packages with Lisp, Java, design and API doc, and user doc (i.e., html and/or info help files). How does this sound to you? I won't do this until somebody actually writes a genuinely useful plugin that I could use to test the plugin support code. Or perhaps someone could undertake to restructure one of the existing JDEE packages as a plugin, e.g., checkstyle. We could have standard plugins that would ship with the JDEE distribution (e.g., checkstyle) and plugins available independently or
Introspection based Java class browser....also demonstrates alittle bit of java and lisp integration...
To use :
1. unzip the attached zip at in the jde directory
2. Just put the following in your .emacs
(require 'jde-introspect)
Now put the point anywhere in Java buffer where you would
normally invoke jde-complete functions. Then type
(control c) (control v) (/) to see the java typeinfo
buffer.
For example:
With point in the 'System' below :
public class Foo {
public static void main(String[] args) {
System.out.println(args.length);
}
}
here is what you get in a temp buffer. All the java class names are
hyperlinks (activated by
mouse or RET key).
class java.lang.System
/**
* Constructors of class System
**/
private System()
/**
* Methods of class System
**/
public static native void arraycopy(Object, int, Object, int,
int)
public static native int identityHashCode(Object)
public static void exit(int)
public static void runFinalizersOnExit(boolean)
private staticvoid initializeSystemClass()
public static String setProperty(String, String)
private static native void registerNatives()
public static SecurityManager getSecurityManager()
staticClass getCallerClass()
public static void loadLibrary(String)
public static String getProperty(String)
public static String getProperty(String, String)
public static native String mapLibraryName(String)
public static void load(String)
public static void setIn(InputStream)
public static void setOut(PrintStream)
public static void setErr(PrintStream)
private staticvoid checkIO()
private static native void setIn0(InputStream)
private static native void setOut0(PrintStream)
private static native void setErr0(PrintStream)
public static void setSecurityManager(SecurityManager)
private static synchronized void setSecurityManager0(SecurityManager)
public static native long currentTimeMillis()
private static native Properties initProperties(Properties)
public static Properties getProperties()
public static void setProperties(Properties)
public static String getenv(String)
public static void gc()
public static void runFinalization()
private staticInputStream nullInputStream() throws
NullPointerException
private staticPrintStream nullPrintStream() throws
NullPointerException
/**
* Fields of class System
**/
public final static InputStream in
public final static PrintStream out
public final static PrintStream err
private staticSecurityManager security
private staticProperties props
jde.zip
Description: Zip compressed data
