RE: Introspection based Java class browser....also demonstrates alittle bit of java and lisp integration...
Sandip,
Just tried it out and ran into unexpected behaviour. Essentially the situation is as
follows. I have in my current buffer a class, say B, which extends a class A. In A I
have a protected object logger which is an instance of a Logger class. In class B I
have the code fragment
logger.debug(...);
When I then press C-c C-v / with point inside the word logger, I do not get
information on the Logger class as I expected from your explanation, but on the class
B and its superclass A.
Sources are in the attached zipfile.
Cheers,
Karel
-Original Message-
From: Sandip Chitale [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 19, 2003 07:32
To: [EMAIL PROTECTED]
Subject: Introspection based Java class browseralso 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
problem.zip
Description: problem.zip
RE: Introspection based Java class browser....also demonstrates alittle bit of java and lisp integration...
Hello,
attached is a small library ecb-jde.el which enables you to display
the contents of class at point in the method-window of ECB:
(defun ecb-jde-display-class-at-point ()
Displays in the ECB-methods-buffer the contents \(methods, attributes
etc...) of the class which contains the definition of the \thing\ under
point \(this can be a variablename, classname, methodname, attributename).
This function needs the same requirements to work as the method-completion
feature of JDE \(see `jde-complete-at-point')!. The source-file is searched
first in `jde-sourcepath', then in `jde-global-classpath', then in $CLASSPATH,
then in current-directory.
(interactive)
...
)
Just do:
1. Save ecb-jde.el somewhere in your load-path - probably best in the
ecb-directory ;-)
2. Activate ECB
3. Open a java-source
4. Load ecb-jde.el, e.g. with M-x load-library RET ecb RET
5. Try it.
Differences to Sandips code:
- uses ECB method-window to display the class-contents
- uses semantic for getting the contents of a class
- needs the source-file of the class to work
The first point can be seen as advantage or disadvantage ;-)
Especially the latter point is a disadvantage because it prevents
from working for classes which are only available as *.class-file or
within a jar-file...
But it demonstrates another elegant way of displaying things of a class
under point without needing java-introspection.
Klaus
-Original Message-
From: Sandip Chitale [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 19, 2003 7:32 AM
To: [EMAIL PROTECTED]
Subject: Introspection based Java class browseralso 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
ecb-jde.el
Description: Binary data
Re: JDEE plugins (was JUCI)
Paul == Paul Kinnucan [EMAIL PROTECTED] writes: Paul Hi Nick, Paul I am posting my response to your idea of JUCI-based plugins Paul to the JDEE list because I am interested in getting other Paul people's Paul input on this idea. This sounds like a thoroughly good idea to me. I've contributed lisp to JDE in the past, which is very easy to do, but I've never added Java, because I never got the build working on a unix box. I was looking at jrefactory the other day, and thought that would be nice to integrate in, but it needs some Java code in the way. And then the whole thing needs to be made available to JDE, so that it can be run from bsh. A simple plugin architecture would make this all easier. So, yeah, sounds sensible to me. Phil
auto-delete compile buffer
Hi, I really love the new feature that the frame-split into source and compilation buffer disappears magically when there was no compilation error. I would love to see this to be taken a step further: Is it somehow possible to actually remove the compilation buffer? Or to place it somewhere else in the buffer-history? I'm usually using the C-Meta-l (XEmacs) keys to switch fast between the last two buffers visited. Now when a compilation has been done, pressing this keys will show the compilation buffer to me. Thanks for your help, Diez B. Roggisch
RE: JDEE plugins (was JUCI)
I second those sentiments and that motion. / Petter -Original Message- From: Mark Pollack [mailto:[EMAIL PROTECTED]] Sent: den 19 februari 2003 02:01 To: Paul Kinnucan; Nascif Abousalh-Neto Cc: [EMAIL PROTECTED] Subject: 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
Re: Introspection based Java class browser....also demonstrates alittle bit of java and lisp integration...
In principal you do the following:
1. Getting the class of current point
2. Introspection with java-code of this class
Here is your code
,
| (defun jde-introspect-javatype-at-point ()
| (interactive)
| (if (jde-open-functions-exist)
| (let* ((thing-of-interest (thing-at-point 'symbol))
| (pair (save-excursion (end-of-thing 'symbol)
|(jde-parse-java-variable-at-point)))
| (class-to-open (jde-open-get-class-to-open ;; step 1.
| pair thing-of-interest))
|)
| (if (and class-to-open (stringp class-to-open))
| (jde-introspect-javatype class-to-open) ;; step 2.
| (error Can not parse the thing at point!)))
| (message You need JDE = 2.2.6 and Senator for using this feature!)))
`
IMHO step 1. is enough and step 2 can be done much smarter with semantic
because this tool already offers all what we need for getting the contents of
a class!
I would do the following:
1. Getting the class C of current point like in your code.
2. Opening the file F which contains class C with find-file-noselect in a
hidden buffer
(save-excursion
(set-buffer (find-file-noselect file of class c))
)
3. In this buffer just call `senator-parse' or `semantic-bovinate-toplevel'
which return all tokens in this file. The library semantic-util.el offers a
lot to display and bucketize these tokens in several manners (e.g. like in
UML-notation).
(save-excursion
(set-buffer (find-file-noselect file of class c))
(let ((tokens (senator-parse)))
;; do something with the tokens, e.g. display it in a special buffer
)
)
4. If you use ECB you can use its methods buffer to display the contents of
class under point with the following short code:
(save-excursion
(set-buffer (find-file-noselect file of class c))
(ecb-update-methods-buffer--internal 'scroll-to-begin)
)
You do not need more code to display the methods and variables of class C
under point in the methods-buffer of ECB!
IMHO this is much easier than using this somehow clumsy beanshell to
communicate between java and elisp. IMHO java/Beanshell is good to find out in
which file a class/method is defined, but the rest of the job can be done
very easy with semantic (and ECB if you like).
But do not misunderstand me: Your code is good and a really stringent
mechanism for code-completion/introspection/browsing etc. is really needed in
JDEE. IMHO currently there are too many different mechanisms in JDEE to do
this things.
Ciao,
Klaus
On Tue, 18 Feb 2003, Sandip Chitale wrote:
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
Re: Introspection based Java class browser....also demonstrates alittle bit of java and lisp integration...
On Wed, 19 Feb 2003, Karel Sprenger wrote:
Hello,
Ironically enough, the method ecb-jde-display-class-at-point shows the same
behaviour as Sandip's code when I invoke it with point in the variable
logger in class B.
Of course, this must be because Sandips and my code use the same JDE code to
get the class for the thing under point. Or with other words: Both uses the
JDE mechanism used for method/field-completion.
The following code is responsible for getting the class:
,
| (let* (
| (thing-of-interest (thing-at-point 'symbol))
| (pair (save-excursion (end-of-thing 'symbol)
|(jde-parse-java-variable-at-point)))
| (class-to-open (jde-open-get-class-to-open
| pair thing-of-interest))
| (source-path-prefix-list (jde-open-get-path-prefix-list))
| (java-file-name nil)
| )
| (if (and class-to-open (stringp class-to-open))
| (progn
| (setq java-file-name (jde-open-find-java-file-name
| class-to-open source-path-prefix-list))
| (if (not java-file-name)
| ;; here comes the code which displays contents of
| ;; java-file-name
`
Exactly the same mechanism is used by jde-open-class-at-point and also
also jde-complete.
See jde-open-source.el!
Sandips and my code are equal in getting the correct class and different in
getting and displaying the contents of this class.
Ciao,
Klaus
public class A {
protected Logger logger = new Logger();
public A() {
}
public String toString() {
logger.debug(A.toString() invoked.);
return A;
}
}
public class B extends A {
public B() {
}
public String toString() {
logger.debug(B.toString() invoked.);
// ^-- invoke ecb-jde-display-class-at-point here
return B;
}
}
If I invoke ecb-jde-display-class-at-point with point inside logger in the
toString method of class A, all is well and I get:
Logger [-]
Varia... [+]
Logger()
Logger(String)
void debug(String)
void debug(String,Throwable)
void error(String)
void error(String,Throwable)
void info(String)
void info(String,Throwable)
void warn(String)
void warn(String,Throwable)
Invoking ecb-jde-display-class-at-point with point inside logger in B's
toString method will show
B [-]
Parents [+]
+ B()
+ String toString()
Is this a semantic problem?
Cheers, Karel -Original Message- From: Berndl, Klaus
[mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 19, 2003 11:07 To:
'Sandip Chitale'; [EMAIL PROTECTED] Subject: RE: Introspection based Java
class browseralso demonstrates alittle bit of java and lisp
integration...
Hello,
attached is a small library ecb-jde.el which enables you to display
the contents of class at point in the method-window of ECB:
(defun ecb-jde-display-class-at-point ()
Displays in the ECB-methods-buffer the contents \(methods, attributes
etc...) of the class which contains the definition of the \thing\ under
point \(this can be a variablename, classname, methodname, attributename).
This function needs the same requirements to work as the method-completion
feature of JDE \(see `jde-complete-at-point')!. The source-file is searched
first in `jde-sourcepath', then in `jde-global-classpath', then in
$CLASSPATH, then in current-directory.
(interactive)
...
)
Just do:
1. Save ecb-jde.el somewhere in your load-path - probably best in the
ecb-directory ;-)
2. Activate ECB
3. Open a java-source
4. Load ecb-jde.el, e.g. with M-x load-library RET ecb RET
5. Try it.
Differences to Sandips code:
- uses ECB method-window to display the class-contents
- uses semantic for getting the contents of a class
- needs the source-file of the class to work
The first point can be seen as advantage or disadvantage ;-)
Especially the latter point is a disadvantage because it prevents
from working for classes which are only available as *.class-file or
within a jar-file...
But it demonstrates another elegant way of displaying things of a class
under point without needing java-introspection.
Klaus
-Original Message- From: Sandip Chitale
[mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 19, 2003 7:32 AM
To: [EMAIL PROTECTED] Subject: Introspection based Java class browseralso
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 :
Re: Introspection based Java class browser....also demonstrates alittle bit of java and lisp integration...
Klaus Berndl writes: IMHO this is much easier than using this somehow clumsy beanshell to communicate between java and elisp. Easier for whom? The easiest way to implement a feature does not necessarily result in the implementation that is easiest to use. For example, your proposal for implementing completion works only for classes for which source code is available and requires opening and parsing the source file of each class to be completed during a session. Ever tried opening and parsing a large Java source file? Think of how long it would take to complete a method of JFrame class. People already complain about how long the existing JDEE feature takes. Your proposal would decrease the response time exponentially. semantic includes a database feature whereby it can save parsed versions of source files so that they don't need to be opened and parsed every time parse data is needed. The parsed info for all the source files in a directory are saved in a separate file in that directory named semantic.db. In principal, semantic.db could be used as a basis for completion. But a pure semantic.db-based implementation has some significant drawbacks compared to the present Java introspection-based completion: * No support for class files for which there is no source code * Requires prior creation of the semantic.db. For example, a semantic.db would have to be created for the entire JDK source files. It would be possible to provide semantic.db's for the JDK. * Requires loading and saving the semantic.db for each source directory that is visited in a session. This slows down opening Emacs (if you use Emacs' desktop feature, which I do) and closing Emacs substantially. In fact, the slow down is so annoying that I have turned off the semantic.db feature. * Requires improving the current interface to semantic.db. The current semantic.db implementation does not support Java's package-based scheme for quickly locating source and class files on a user's system. This support is essential to ensure reasonable response time for any feature based on semantic.db files. Put another way, the current Java introspection-based implementation of completion is faster, does not require a separate parse database, and works for all classes for which a class file exists on jde-global-classpath. The only advantage of a semantic.db-based approach that I can see at this point is that it would work for uncompiled classes. For this reason, it does not make sense to me to dump the current JDEE approach (let's call it the classpath-based approach) for the semantic.db approach (let's call it the sourcepath-based approach). You gain one minor advantage in return for several major disadvantages. My plan has been to merge the classpath and source path approaches so as to have a completion/browser facility that works whether only class files are available, only source files, or both. Under this approach, the JDEE would search the sourcepath first for parse data (i.e., use semantic.db) for a class and if nothing turned up, it would search the classpath (i.e., use Java instrospection via the Beanshell). To do this efficiently requires abstracting the semantic.db search mechanism so that the sourcepath and the classpath appear the same to clients of the search mechanism. I started work on this last spring with Eric Ludlum, semantic's author, but dropped it because of other JDEE work that was more pressing and also because semantic was currently in a great deal of flux. - Paul IMHO java/Beanshell is good to find out in which file a class/method is defined, but the rest of the job can be done very easy with semantic (and ECB if you like). But do not misunderstand me: Your code is good and a really stringent mechanism for code-completion/introspection/browsing etc. is really needed in JDEE. IMHO currently there are too many different mechanisms in JDEE to do this things.
Re: Introspection based Java class browser....also demonstrates alittle bit of java and lisp integration...
Sprenger, Karel [EMAIL PROTECTED] writes: Hello, [...] Is this a semantic problem? No. Completion looks for the logger class type by parsing the current java file. (jde-parse-declared-type-of) The method is not smart enough to look for it in the super class or classes within the same package. I will take a look at it later, it should be straightforward to use semantic to add the functionality to look for the variable in the super class. Javier
Re[2]: Introspection based Java class browser....also demonstrates alittle bit of java and lisp integration...
Berndl, Klaus [EMAIL PROTECTED] seems to think that: [ ... ] Differences to Sandips code: - uses ECB method-window to display the class-contents - uses semantic for getting the contents of a class - needs the source-file of the class to work The first point can be seen as advantage or disadvantage ;-) Especially the latter point is a disadvantage because it prevents from working for classes which are only available as *.class-file or within a jar-file... [ ... ] Hi Klaus, Your last point here about semantic not being able to look into a .class file is valid, however the CVS version semantic 2.0 semanticdb subsystem was recently enhanced to be extensible beyond just typical language parsers. The idea was Paul's originally, and I expanded on that. The basic premise is to sub-class a semanticdb class, and implement all the search methods. Your search methods can then call external programs, or whatever you like before returning a results table. There is an example that will search all Emacs Lisp symbols inside Emacs, regardless of having the sources available. The only part that needs to be done to make your new program support .class files is to extend the database. I can provide you with more details and perhaps start the process if you would like to try extending semanticdb. Have fun Eric -- Eric Ludlam: [EMAIL PROTECTED], [EMAIL PROTECTED] Home: http://www.ludlam.netSiege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org
Re: auto-delete compile buffer
Hi, Javier S. Lopez wrote: The method jde-compile-finish-kill-buffer takes care of removing the compilation window from the screen. if you add this lines: (run-at-time 3 sec nil 'kill-buffer (get-buffer-create *compilation*)) to your jde-compile-finish-kill-buffer method after the lines: (get-buffer-create *compilation*) I created this function: (defun jde-compile-finish-kill-buffer (buf msg) Removes the jde-compile window after a few seconds if no errors. (save-excursion (set-buffer buf) (if (null (or (string-match .*exited abnormally.* msg) (string-match .*BUILD FAILED.* (buffer-string ;;no errors, make the compilation window go away in a few seconds (progn (run-at-time 2 sec nil 'delete-windows-on (get-buffer-create *compilation*) (run-at-time 2 sec nil 'kill-buffer (get-buffer-create *compilation*))) (message No compilation errors)) ;;there were errors, so jump to the first error (next-error However, its not working the way I wanted it to: it kills the buffer, but now the frame split persits :( Any suggestions? Regards, Diez
RE: auto-delete compile buffer
I created this function: I think it has to be: (defun jde-compile-finish-kill-buffer (buf msg) Removes the jde-compile window after a few seconds if no errors. (save-excursion (set-buffer buf) (if (null (or (string-match .*exited abnormally.* msg) (string-match .*BUILD FAILED.* (buffer-string ;;no errors, make the compilation window go away in a few seconds (progn (run-at-time 2 sec nil 'delete-windows-on (get-buffer-create *compilation*)) (run-at-time 2 sec nil 'kill-buffer (get-buffer-create *compilation*)) (message No compilation errors)) ;;there were errors, so jump to the first error (next-error Klaus
Re: auto-delete compile buffer
On Wed, 19 Feb 2003, Diez B. Roggisch wrote: Hi, Javier S. Lopez wrote: The method jde-compile-finish-kill-buffer takes care of removing the compilation window from the screen. if you add this lines: (run-at-time 3 sec nil 'kill-buffer (get-buffer-create *compilation*)) to your jde-compile-finish-kill-buffer method after the lines: (get-buffer-create *compilation*) I created this function: (defun jde-compile-finish-kill-buffer (buf msg) Removes the jde-compile window after a few seconds if no errors. (save-excursion (set-buffer buf) (if (null (or (string-match .*exited abnormally.* msg) (string-match .*BUILD FAILED.* (buffer-string ;;no errors, make the compilation window go away in a few seconds (progn (run-at-time 2 sec nil 'delete-windows-on (get-buffer-create *compilation*) (run-at-time 2 sec nil 'kill-buffer (get-buffer-create *compilation*))) (message No compilation errors)) ;;there were errors, so jump to the first error (next-error I think it has to be: (defun jde-compile-finish-kill-buffer (buf msg) Removes the jde-compile window after a few seconds if no errors. (save-excursion (set-buffer buf) (if (null (or (string-match .*exited abnormally.* msg) (string-match .*BUILD FAILED.* (buffer-string ;;no errors, make the compilation window go away in a few seconds (progn (run-at-time 2 sec nil 'delete-windows-on (get-buffer-create *compilation*)) (run-at-time 2 sec nil 'kill-buffer (get-buffer-create *compilation*)) (message No compilation errors)) ;;there were errors, so jump to the first error (next-error Klaus However, its not working the way I wanted it to: it kills the buffer, but now the frame split persits :( Any suggestions? Regards, Diez -- Klaus Berndlmailto: [EMAIL PROTECTED] sdm AG http://www.sdm.de software design management Thomas-Dehler-Str. 27, 81737 München, Germany Tel +49 89 63812-392, Fax -220
RE: Introspection based Java class browser....also demonstrates alittle bit of java and lisp integration...
A few more feature people might have missed are -
1. The output of the tool is hyperlinked. In other words by
putting the point on any java type in the output and hitting RET key
Invokes the tool on that type.
2. It attempts to display values of static final variables (including
Private ones).
3. Additional bindings :
[(return)] 'jde-introspect-javatype-by-xref-at-point ; run tool
on the class at point in the output buffer
[(control return)] 'jde-open-source-javatype-by-xref-at-point ; show
source of class at point in the output buffer
[(control shift return)] 'jde-help-javatype-by-xref-at-point ; show
java doc of class at point in the output buffer
[(down-mouse-1)] 'jde-introspect-javatype-by-xref-at-point; mouse
based interface to above
[(C-down-mouse-1)] 'jde-open-source-javatype-by-xref-at-point ;
[(tab)] 'jde-introspect-next-ref ; goto
next hyperlink
[(shift tab)] 'jde-introspect-previous-ref; goto
previous hyperlink
Sandip
-Original Message-
From: Berndl, Klaus [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 19, 2003 2:07 AM
To: 'Sandip Chitale'; [EMAIL PROTECTED]
Subject: RE: Introspection based Java class browseralso demonstrates
alittle bit of java and lisp integration...
Hello,
attached is a small library ecb-jde.el which enables you to display the
contents of class at point in the method-window of ECB:
(defun ecb-jde-display-class-at-point ()
Displays in the ECB-methods-buffer the contents \(methods, attributes
etc...) of the class which contains the definition of the \thing\
under point \(this can be a variablename, classname, methodname,
attributename). This function needs the same requirements to work as the
method-completion feature of JDE \(see `jde-complete-at-point')!. The
source-file is searched first in `jde-sourcepath', then in
`jde-global-classpath', then in $CLASSPATH, then in current-directory.
(interactive)
...
)
Just do:
1. Save ecb-jde.el somewhere in your load-path - probably best in the
ecb-directory ;-)
2. Activate ECB
3. Open a java-source
4. Load ecb-jde.el, e.g. with M-x load-library RET ecb RET
5. Try it.
Differences to Sandips code:
- uses ECB method-window to display the class-contents
- uses semantic for getting the contents of a class
- needs the source-file of the class to work
The first point can be seen as advantage or disadvantage ;-)
Especially the latter point is a disadvantage because it prevents from
working for classes which are only available as *.class-file or within a
jar-file...
But it demonstrates another elegant way of displaying things of a class
under point without needing java-introspection.
Klaus
-Original Message-
From: Sandip Chitale [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 19, 2003 7:32 AM
To: [EMAIL PROTECTED]
Subject: Introspection based Java class browseralso 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
RE: JDEE plugins (was JUCI)
As a long time Emacs and JDE user (I think I first started using JDE in 1997) I have to throw in my 2cents and say that I'd be hugely excited with any work made towards making plugins written in Java easy to integrate with JDE. Until recently I think Emacs has been unsurpassed as the editor to use for Java, but I think some of the IDE's are catching up, specifically IntelliJ which most people I work with use. There are a few features there which I think would be easy to implement as JDE plugins (especially using reflection) but as Nascif says, I have neither the time or desire to brush up my lisp skills to do so. If it were possible to create some basic interfaces that pure Java plugins could write to I think that would go a long way towards keeping us able to taunt other users with our editor. :) From the top of my head, these type of operations bound to a JDE plugin would allow for some neat development: Input into the plugin: - class at point - object name at point - point context (what method, what class) - (user input data from minibuffer) Output from plugin: - direct output to new buffer with name.. - direct output to new buffer in split pane - insert output into current buffer at position - some way of replacing current word with output? - display menu at point? If you could bind lisp commands to a java plugin with the type of input then it might allow for a bunch of new development. I for one would spend the time to do some new things. -Nic -Original Message- From: Nascif Abousalh-Neto [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 19, 2003 8:35 AM To: Paul Kinnucan Cc: [EMAIL PROTECTED] Subject: RE: JDEE plugins (was JUCI) Hi Paul, Just to recap: 1) The plug-in will follow the proposed directory structure; 2) It will have a lisp/plugin.el file that will be evaluated at load time by JDE (still not sure what goes here, any suggestion?); 3) It can assume that its libraries will be in the BeanShell classpath; 4) Based on (3), it can replace direct invocations of the JVM with jde-eval calls (which should make it much faster) Problem with (4) is how to get the output to a compilation buffer. When I launch a new JVM process myself, I can just redirect the output to any buffer I choose; if I launch the Java portion of the plug-in from the BeanShell, the output goes to stdout, which is captured as lisp forms by the BeanShell, right? Sorry if that is a basic elisp question, but how do I redirect that output to a compilation buffer? I guess I could use that code you mentioned. I looked at the code at jde-checkstyle.el for an example but my impression is that it launches an new JVM for each invocation instead of using the BeanShell, is that correct? As a first pass it should be OK for the plugin to do the same, but then we will be missing an opportunity for code re-use. I agree with the others that the less elisp requirements we have the larger will be the pool of plug-in contributors; I believe JUCI will be able to help us with this part; maybe some elisp code generation facility based on Java Reflection or config files could also complement it. I think the final design goals should be: 1) Drop-in install; just adding a jar or zip file to a specific directory would be sufficient to install the package and integrate it with JDEE menus; 1.1) With a plug-in manager menu to enable/disable plug-ins; 2) Minimal to none elisp code required. I think we will have elisp-based plug-ins as well, but I expect most to be Java-based - just because most JDEE users know Java much better than they know Lisp. What would be the list of resources available to the Java code in the plug-ins? Any ideas on how to make Emacs/JDEE resources like buffers, point position, region content, files in sourcepath, etc. easily available? Maybe a basic class that they could extend? We have to define the container environment for the plug-ins. Finally, how do we manage different versions of common Java libraries (like XML parsers) among plug-ins? Regards, Nascif
RE: Introspection based Java class browser....also demonstrates alittle bit of java and lisp integration...
Bernadl
I am in Buffer A.java. I use ecb-jde-display-class-at-point to show
methods of B.java. But I am still in A.java buffer. How do I tell ecb to
show the methods of A.java.
-Original Message-
From: Berndl, Klaus [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 19, 2003 2:07 AM
To: 'Sandip Chitale'; [EMAIL PROTECTED]
Subject: RE: Introspection based Java class browseralso demonstrates
alittle bit of java and lisp integration...
Hello,
attached is a small library ecb-jde.el which enables you to display
the contents of class at point in the method-window of ECB:
(defun ecb-jde-display-class-at-point ()
Displays in the ECB-methods-buffer the contents \(methods, attributes
etc...) of the class which contains the definition of the \thing\
under
point \(this can be a variablename, classname, methodname,
attributename).
This function needs the same requirements to work as the
method-completion
feature of JDE \(see `jde-complete-at-point')!. The source-file is
searched
first in `jde-sourcepath', then in `jde-global-classpath', then in
$CLASSPATH,
then in current-directory.
(interactive)
...
)
Just do:
1. Save ecb-jde.el somewhere in your load-path - probably best in the
ecb-directory ;-)
2. Activate ECB
3. Open a java-source
4. Load ecb-jde.el, e.g. with M-x load-library RET ecb RET
5. Try it.
Differences to Sandips code:
- uses ECB method-window to display the class-contents
- uses semantic for getting the contents of a class
- needs the source-file of the class to work
The first point can be seen as advantage or disadvantage ;-)
Especially the latter point is a disadvantage because it prevents
from working for classes which are only available as *.class-file or
within a jar-file...
But it demonstrates another elegant way of displaying things of a class
under point without needing java-introspection.
Klaus
-Original Message-
From: Sandip Chitale [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 19, 2003 7:32 AM
To: [EMAIL PROTECTED]
Subject: Introspection based Java class browseralso 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
RE: JDEE plugins (was JUCI)
snip/ Until recently I think Emacs has been unsurpassed as the editor to use for Java, but I think some of the IDE's are catching up, specifically IntelliJ which most people I work with use. There are a few features there which I think would be easy to implement as JDE plugins (especially using reflection) but as Nascif says, I have neither the time or desire to brush up my lisp skills to do so. If it were possible to create some basic interfaces that pure Java plugins could write to I think that would go a long way towards keeping us able to taunt other users with our editor. :) I echo that remark.. I've been using JDE for several years and I have always been able to defend it vs. things like JBuilder, Visual Café, and to some extent, VAJ. But now, Eclipse and IntelliJ are blowing JDE away.. Now, I love Emacs and think its editor is far superior to all the rest. And until now, I've always selected Emacs + JDE over anything these IDEs offered - GUI Swing/servlet/ejb wizards, etc. Now, it seems JDE has reached the end of its extensibility until this plugin design is factored in. So, now that the plugin arch is being acknowledged as a must for JDE to grow as fast as the current IDEs, I have to ask: 1) What are the biggest hurdles to get JDE using this new plugin arch - people, time, technology? 2) Is going JDE, versus integrating the Emacs editor into today's IDEs, the right way to solve this problem (i.e. which is more work - redesigning JDE or bridging a native editor into today's popular IDEs to gain their infrastructure and Emacs's editing capabilities)? 3) Should JDE be examining and/or joining JSR-198 to see if we should be following this plugin API now, such that JDE will be compliant in the future? Thus, the JDE plugin code won't have to change again in a few months to allow JDE to take advantage of upcoming JSR198-compliant plugins? Just throwing out some comments to get the ball rolling. It seems everyone is up for this idea, so my hope is to get us thinking in the proper frame of mind, as this plugin architecture may require enough redesign to rethink the way JDE works now. I'm obviously not a JDE team member, nor have I done much LISP, so some or all of my assumptions could be slightly-to-way off. All I know is that these current IDEs are giving JDE a run mostly because its written in the same language as the programmer uses, reducing the barrier to entry for extending it. This plugin idea is like the right thing to do (and not doing it would jeopardize JDE's effectiveness IMO), but I want to make sure that JDE is still focusing on the right approach, not just taking the approach because that's the way its been done in the past. Best Regards, James
RE: Introspection based Java class browser....also demonstrates alittle bit of java and lisp integration...
OK I got the answer. When you use C-c . 1 and come back to the source
buffer, the methods window changes back to show the methods of the
buffer you are in.
-Original Message-
From: Jayakrishnan Nair [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 19, 2003 9:18 AM
To: [EMAIL PROTECTED]
Subject: RE: Introspection based Java class browseralso demonstrates
alittle bit of java and lisp integration...
Bernadl
I am in Buffer A.java. I use ecb-jde-display-class-at-point to show
methods of B.java. But I am still in A.java buffer. How do I tell ecb to
show the methods of A.java.
-Original Message-
From: Berndl, Klaus [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 19, 2003 2:07 AM
To: 'Sandip Chitale'; [EMAIL PROTECTED]
Subject: RE: Introspection based Java class browseralso demonstrates
alittle bit of java and lisp integration...
Hello,
attached is a small library ecb-jde.el which enables you to display
the contents of class at point in the method-window of ECB:
(defun ecb-jde-display-class-at-point ()
Displays in the ECB-methods-buffer the contents \(methods, attributes
etc...) of the class which contains the definition of the \thing\
under
point \(this can be a variablename, classname, methodname,
attributename).
This function needs the same requirements to work as the
method-completion
feature of JDE \(see `jde-complete-at-point')!. The source-file is
searched
first in `jde-sourcepath', then in `jde-global-classpath', then in
$CLASSPATH,
then in current-directory.
(interactive)
...
)
Just do:
1. Save ecb-jde.el somewhere in your load-path - probably best in the
ecb-directory ;-)
2. Activate ECB
3. Open a java-source
4. Load ecb-jde.el, e.g. with M-x load-library RET ecb RET
5. Try it.
Differences to Sandips code:
- uses ECB method-window to display the class-contents
- uses semantic for getting the contents of a class
- needs the source-file of the class to work
The first point can be seen as advantage or disadvantage ;-)
Especially the latter point is a disadvantage because it prevents
from working for classes which are only available as *.class-file or
within a jar-file...
But it demonstrates another elegant way of displaying things of a class
under point without needing java-introspection.
Klaus
-Original Message-
From: Sandip Chitale [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 19, 2003 7:32 AM
To: [EMAIL PROTECTED]
Subject: Introspection based Java class browseralso 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
Re: Introspection based Java class browser....also demonstrates alittle bit of java and lisp integration...
This is interesting. I know you've mentioned it before. If this would help the JDE project, I could do this fairly easily. We have the class parsing code already, we just have to tie it into semantic. But since we are not using the latest Semantic, and as far as I know we have no immediate need to change the way we do introspection, for the time being, I will hold off on doing this. Eric M. Ludlam [EMAIL PROTECTED] writes: Hi Klaus, Your last point here about semantic not being able to look into a .class file is valid, however the CVS version semantic 2.0 semanticdb subsystem was recently enhanced to be extensible beyond just typical language parsers. The idea was Paul's originally, and I expanded on that. The basic premise is to sub-class a semanticdb class, and implement all the search methods. Your search methods can then call external programs, or whatever you like before returning a results table. There is an example that will search all Emacs Lisp symbols inside Emacs, regardless of having the sources available. The only part that needs to be done to make your new program support .class files is to extend the database. I can provide you with more details and perhaps start the process if you would like to try extending semanticdb. Have fun Eric -- Eric Ludlam: [EMAIL PROTECTED], [EMAIL PROTECTED] Home: http://www.ludlam.netSiege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org
RE: JDEE plugins (was JUCI)
Hi James, Thanks for your e-mail, and agreed in all points. I didn't realize that there is a JSR going on for plug-ins, it is really a good idea to take a look at it and try to conform. Once I thought about peeking one of the more mature plug-in APIs like OpenTools for JBuilder and try to emulate, so that we could re-use their already made plug-ins. But that are problems with that - you're now tied to a commercial API - so a JSR-compliant API makes much more sense. As for your questions: 1) I would say people and technology are the major problems (we don't have a deadline). From my little experience in this area, anything other than very trivial plug-ins (basically launching a Java app to process the current buffer and capture the results) requires a fair amount of elisp knowledge. And as far as technology, as we discussed before in this list, it is quite hard to get the Java code to drive the control flow (allowing it to change the contents of the buffer, change the cursor position, open new windows, etc.). It can be done but it depends on interprocess communications, which adds a lot of complexity. I used gnuclient for that purposes, Paul used direct socket communication in the JDEbug. The JUCI package will I believe address this problem in a generic way. 2) I think extending JDE is the way to go. Note that it is quite easy, today, to integrate Emacs in many IDEs by using gnuclient. 3) As I said above, this looks like a great idea. It may be the case that we won't be able for performance or other reasons to have a 100% Pure Java plug-in API; but if we can, by all means it should follow a standard. Regards, Nascif -Original Message- From: James Higginbotham [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 19, 2003 12:21 PM To: Nic Pottier; Abousalh-Neto, Nascif [NCRTP:3X20:EXCH]; Paul Kinnucan Cc: [EMAIL PROTECTED] Subject: RE: JDEE plugins (was JUCI) snip/ Until recently I think Emacs has been unsurpassed as the editor to use for Java, but I think some of the IDE's are catching up, specifically IntelliJ which most people I work with use. There are a few features there which I think would be easy to implement as JDE plugins (especially using reflection) but as Nascif says, I have neither the time or desire to brush up my lisp skills to do so. If it were possible to create some basic interfaces that pure Java plugins could write to I think that would go a long way towards keeping us able to taunt other users with our editor. :) I echo that remark.. I've been using JDE for several years and I have always been able to defend it vs. things like JBuilder, Visual Café, and to some extent, VAJ. But now, Eclipse and IntelliJ are blowing JDE away.. Now, I love Emacs and think its editor is far superior to all the rest. And until now, I've always selected Emacs + JDE over anything these IDEs offered - GUI Swing/servlet/ejb wizards, etc. Now, it seems JDE has reached the end of its extensibility until this plugin design is factored in. So, now that the plugin arch is being acknowledged as a must for JDE to grow as fast as the current IDEs, I have to ask: 1) What are the biggest hurdles to get JDE using this new plugin arch - people, time, technology? 2) Is going JDE, versus integrating the Emacs editor into today's IDEs, the right way to solve this problem (i.e. which is more work - redesigning JDE or bridging a native editor into today's popular IDEs to gain their infrastructure and Emacs's editing capabilities)? 3) Should JDE be examining and/or joining JSR-198 to see if we should be following this plugin API now, such that JDE will be compliant in the future? Thus, the JDE plugin code won't have to change again in a few months to allow JDE to take advantage of upcoming JSR198-compliant plugins? Just throwing out some comments to get the ball rolling. It seems everyone is up for this idea, so my hope is to get us thinking in the proper frame of mind, as this plugin architecture may require enough redesign to rethink the way JDE works now. I'm obviously not a JDE team member, nor have I done much LISP, so some or all of my assumptions could be slightly-to-way off. All I know is that these current IDEs are giving JDE a run mostly because its written in the same language as the programmer uses, reducing the barrier to entry for extending it. This plugin idea is like the right thing to do (and not doing it would jeopardize JDE's effectiveness IMO), but I want to make sure that JDE is still focusing on the right approach, not just taking the approach because that's the way its been done in the past. Best Regards, James
RE: JDEE plugins (was JUCI)
Well, looks like I jumped the gun. There is not API to look at yet for this JSR 198. I suggest we just move ahead (who know long it will take to get to a point where actual APIs are defined, this looks like a very hot politic issue as well http://news.com.com/2100-1001-978445.html) and later consider a move to conform to whatever they define. In the mean time we will learn a lot :-) -Original Message- From: James Higginbotham [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 19, 2003 12:21 PM To: Nic Pottier; Abousalh-Neto, Nascif [NCRTP:3X20:EXCH]; Paul Kinnucan Cc: [EMAIL PROTECTED] Subject: RE: JDEE plugins (was JUCI) snip/ Until recently I think Emacs has been unsurpassed as the editor to use for Java, but I think some of the IDE's are catching up, specifically IntelliJ which most people I work with use. There are a few features there which I think would be easy to implement as JDE plugins (especially using reflection) but as Nascif says, I have neither the time or desire to brush up my lisp skills to do so. If it were possible to create some basic interfaces that pure Java plugins could write to I think that would go a long way towards keeping us able to taunt other users with our editor. :) I echo that remark.. I've been using JDE for several years and I have always been able to defend it vs. things like JBuilder, Visual Café, and to some extent, VAJ. But now, Eclipse and IntelliJ are blowing JDE away.. Now, I love Emacs and think its editor is far superior to all the rest. And until now, I've always selected Emacs + JDE over anything these IDEs offered - GUI Swing/servlet/ejb wizards, etc. Now, it seems JDE has reached the end of its extensibility until this plugin design is factored in. So, now that the plugin arch is being acknowledged as a must for JDE to grow as fast as the current IDEs, I have to ask: 1) What are the biggest hurdles to get JDE using this new plugin arch - people, time, technology? 2) Is going JDE, versus integrating the Emacs editor into today's IDEs, the right way to solve this problem (i.e. which is more work - redesigning JDE or bridging a native editor into today's popular IDEs to gain their infrastructure and Emacs's editing capabilities)? 3) Should JDE be examining and/or joining JSR-198 to see if we should be following this plugin API now, such that JDE will be compliant in the future? Thus, the JDE plugin code won't have to change again in a few months to allow JDE to take advantage of upcoming JSR198-compliant plugins? Just throwing out some comments to get the ball rolling. It seems everyone is up for this idea, so my hope is to get us thinking in the proper frame of mind, as this plugin architecture may require enough redesign to rethink the way JDE works now. I'm obviously not a JDE team member, nor have I done much LISP, so some or all of my assumptions could be slightly-to-way off. All I know is that these current IDEs are giving JDE a run mostly because its written in the same language as the programmer uses, reducing the barrier to entry for extending it. This plugin idea is like the right thing to do (and not doing it would jeopardize JDE's effectiveness IMO), but I want to make sure that JDE is still focusing on the right approach, not just taking the approach because that's the way its been done in the past. Best Regards, James
RE: JDEE plugins (was JUCI)
Ah, thanks for the information. I actually first heard of the JSR from the JLense team, which produced a Swing equiv to the Eclipse APIs in an effort to produce a more J2SDK-friendly approach to writing rich client applications. It seems they are on the JSR in an attempt to better understand how their framework can support the JSR in the future. For now, looking at Eclipse and JBuilder APIs will probably expose the most common needs for JDE, and if the JSR succeeds, you can add the support then. Thanks for the news link, it was quite informative! James -Original Message- From: Nascif Abousalh-Neto [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 19, 2003 11:47 AM To: James Higginbotham; Nic Pottier; Paul Kinnucan Cc: [EMAIL PROTECTED] Subject: RE: JDEE plugins (was JUCI) Well, looks like I jumped the gun. There is not API to look at yet for this JSR 198. I suggest we just move ahead (who know long it will take to get to a point where actual APIs are defined, this looks like a very hot politic issue as well http://news.com.com/2100-1001-978445.html) and later consider a move to conform to whatever they define. In the mean time we will learn a lot :-) -Original Message- From: James Higginbotham [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 19, 2003 12:21 PM To: Nic Pottier; Abousalh-Neto, Nascif [NCRTP:3X20:EXCH]; Paul Kinnucan Cc: [EMAIL PROTECTED] Subject: RE: JDEE plugins (was JUCI) snip/ Until recently I think Emacs has been unsurpassed as the editor to use for Java, but I think some of the IDE's are catching up, specifically IntelliJ which most people I work with use. There are a few features there which I think would be easy to implement as JDE plugins (especially using reflection) but as Nascif says, I have neither the time or desire to brush up my lisp skills to do so. If it were possible to create some basic interfaces that pure Java plugins could write to I think that would go a long way towards keeping us able to taunt other users with our editor. :) I echo that remark.. I've been using JDE for several years and I have always been able to defend it vs. things like JBuilder, Visual Café, and to some extent, VAJ. But now, Eclipse and IntelliJ are blowing JDE away.. Now, I love Emacs and think its editor is far superior to all the rest. And until now, I've always selected Emacs + JDE over anything these IDEs offered - GUI Swing/servlet/ejb wizards, etc. Now, it seems JDE has reached the end of its extensibility until this plugin design is factored in. So, now that the plugin arch is being acknowledged as a must for JDE to grow as fast as the current IDEs, I have to ask: 1) What are the biggest hurdles to get JDE using this new plugin arch - people, time, technology? 2) Is going JDE, versus integrating the Emacs editor into today's IDEs, the right way to solve this problem (i.e. which is more work - redesigning JDE or bridging a native editor into today's popular IDEs to gain their infrastructure and Emacs's editing capabilities)? 3) Should JDE be examining and/or joining JSR-198 to see if we should be following this plugin API now, such that JDE will be compliant in the future? Thus, the JDE plugin code won't have to change again in a few months to allow JDE to take advantage of upcoming JSR198-compliant plugins? Just throwing out some comments to get the ball rolling. It seems everyone is up for this idea, so my hope is to get us thinking in the proper frame of mind, as this plugin architecture may require enough redesign to rethink the way JDE works now. I'm obviously not a JDE team member, nor have I done much LISP, so some or all of my assumptions could be slightly-to-way off. All I know is that these current IDEs are giving JDE a run mostly because its written in the same language as the programmer uses, reducing the barrier to entry for extending it. This plugin idea is like the right thing to do (and not doing it would jeopardize JDE's effectiveness IMO), but I want to make sure that JDE is still focusing on the right approach, not just taking the approach because that's the way its been done in the past. Best Regards, James
RE: JDEE plugins (was JUCI)
Hi, You and others have raised two related but separate issues: one is the need for plugin-in support and the other is a need for a way to extend the JDEE that requires only Java programming skills. My proposal addresses the first. I believe Nick Sieger's JUCI addresses the second. Perhaps Nick could chime in and explain how. Paul James Higginbotham writes: snip/ Until recently I think Emacs has been unsurpassed as the editor to use for Java, but I think some of the IDE's are catching up, specifically IntelliJ which most people I work with use. There are a few features there which I think would be easy to implement as JDE plugins (especially using reflection) but as Nascif says, I have neither the time or desire to brush up my lisp skills to do so. If it were possible to create some basic interfaces that pure Java plugins could write to I think that would go a long way towards keeping us able to taunt other users with our editor. :) I echo that remark.. I've been using JDE for several years and I have always been able to defend it vs. things like JBuilder, Visual Café, and to some extent, VAJ. But now, Eclipse and IntelliJ are blowing JDE away.. Now, I love Emacs and think its editor is far superior to all the rest. And until now, I've always selected Emacs + JDE over anything these IDEs offered - GUI Swing/servlet/ejb wizards, etc. Now, it seems JDE has reached the end of its extensibility until this plugin design is factored in. So, now that the plugin arch is being acknowledged as a must for JDE to grow as fast as the current IDEs, I have to ask: 1) What are the biggest hurdles to get JDE using this new plugin arch - people, time, technology? 2) Is going JDE, versus integrating the Emacs editor into today's IDEs, the right way to solve this problem (i.e. which is more work - redesigning JDE or bridging a native editor into today's popular IDEs to gain their infrastructure and Emacs's editing capabilities)? 3) Should JDE be examining and/or joining JSR-198 to see if we should be following this plugin API now, such that JDE will be compliant in the future? Thus, the JDE plugin code won't have to change again in a few months to allow JDE to take advantage of upcoming JSR198-compliant plugins? Just throwing out some comments to get the ball rolling. It seems everyone is up for this idea, so my hope is to get us thinking in the proper frame of mind, as this plugin architecture may require enough redesign to rethink the way JDE works now. I'm obviously not a JDE team member, nor have I done much LISP, so some or all of my assumptions could be slightly-to-way off. All I know is that these current IDEs are giving JDE a run mostly because its written in the same language as the programmer uses, reducing the barrier to entry for extending it. This plugin idea is like the right thing to do (and not doing it would jeopardize JDE's effectiveness IMO), but I want to make sure that JDE is still focusing on the right approach, not just taking the approach because that's the way its been done in the past. Best Regards, James
RE: JDEE plugins (was JUCI)
Nascif Abousalh-Neto writes: Hi Paul, Just to recap: 1) The plug-in will follow the proposed directory structure; 2) It will have a lisp/plugin.el file that will be evaluated at load time by JDE (still not sure what goes here, any suggestion?); plugin.el might be useful in conjunction with an autoload.el to avoid loading the entire plugin before it is used. On JDEE startup, if there is a plugin.el and an autoload.el file in the plugin's lisp directory, the JDEE itself will only load and evaluate those two files and add the plugin's lisp directory to the Emacs load-path. In this instance, plugin.el would be a bootstrap file that did the minimum things necessary to make the plugin visible, i.e., add its (autoloaded) commands to the Plugins submenu. The autoload.el file would cause Emacs itself to load any remaining Lisp files in the directory needed to support the plugin's commands. 3) It can assume that its libraries will be in the BeanShell classpath; Yes. 4) Based on (3), it can replace direct invocations of the JVM with jde-eval calls (which should make it much faster) Yes. Problem with (4) is how to get the output to a compilation buffer. When I launch a new JVM process myself, I can just redirect the output to any buffer I choose; if I launch the Java portion of the plug-in from the BeanShell, the output goes to stdout, which is captured as lisp forms by the BeanShell, right? Sorry if that is a basic elisp question, but how do I redirect that output to a compilation buffer? I guess I could use that code you mentioned. I looked at the code at jde-checkstyle.el for an example but my impression is that it launches an new JVM for each invocation instead of using the BeanShell, is that correct? As a first pass it should be OK for the plugin to do the same, but then we will be missing an opportunity for code re-use. The JDEE's compile server and ant server each uses its own compilation-mode buffer to display output from the BeanShell. This is in addition to the comint (interactive user) buffer that is used to start up the BeanShell. The reason that it is possible to have multiple buffers interacting with the BeanShell is that Emacs allows Lisp code to specify and change dynamically the process output handler. The compile server and the ant server, after sending a Java expression to the BeanShell, temporarily replace the standard output handler with their own handler to handle the result of evaluating the expression. My intention is to write an eieio class called bsh-compilation-output-buffer that encapsulates this technique. This would make it trivial for Java plugins to create compilation-style buffers for handling compilation-like output from Java. I agree with the others that the less elisp requirements we have the larger will be the pool of plug-in contributors; I believe JUCI will be able to help us with this part; maybe some elisp code generation facility based on Java Reflection or config files could also complement it. I think the final design goals should be: 1) Drop-in install; just adding a jar or zip file to a specific directory would be sufficient to install the package and integrate it with JDEE menus; I will support jar/zip file plugins. My plan for integrating with menus is for the plugin.el file to invoke a function called jde-plugin-menu that would specify a menu item or submenu to appear on the Plugin menu where the argument would be a standard Emacs easymenu menu specification that specifies the item's label, command, enabling/disabling conditions, format (e.g., checkbox, radiobutton), etc. 1.1) With a plug-in manager menu to enable/disable plug-ins; Have to think about this. 2) Minimal to none elisp code required. I think we will have elisp-based plug-ins as well, but I expect most to be Java-based - just because most JDEE users know Java much better than they know Lisp. What would be the list of resources available to the Java code in the plug-ins? Any ideas on how to make Emacs/JDEE resources like buffers, point position, region content, files in sourcepath, etc. easily available? Maybe a basic class that they could extend? We have to define the container environment for the plug-ins. I'll depend on somebody else to do this. Finally, how do we manage different versions of common Java libraries (like XML parsers) among plug-ins? Good question. - Paul
Newbie Install
Hello to all. I have been watching some of the email traffic on this newsletter and I have yet to see a newbie question. Please forgive me if I am asking the wrong forum. I am trying to setup XEmacs as my Java IDE and to that effect I have installed the JDE. My current configuration is as follows: Linux:2.4 from SuSE 7.1 XEmacs21.4 JDE 1.43* eieio 1.04* elib 1.10* semantic 1.17* speedbar 1.26* *(version information reported by the package admin tool) I am running this on a headless multiprocessor pentium, to which I login from a Windows 2000 box running Reflection X. I have been able to edit, compile and run my java source. However I have not been able to debug. I am using JDEbug with the following configuration: (custom-set-variables '(jde-db-classic-mode-vm t) '(jde-jdk-registry (quote ((1.4.1 . /usr/local/java/jdk '(jde-sourcepath (quote (~/companyx/test))) '(jde-debugger (quote (JDEbug Every time I try to set a breakpoint I get the following error in the minibuffer: (Symbol's function definition is void: line-beginning-position) When I try to exit the JDEbug I get the following error in the minibuffer: (Symbol's value as variable is void: old-assoc) When I start the debugger everything seems to work fine, the following is a capture of the output *** Debugger Output for Process companyx.test.CThread(1) *** Debugger waiting for Emacs to connect to app SIO port 33134. vm started... All threads suspended... Launch command line: java -classic companyx.test.CThread Emacs connected to standard IO port 33134 for process companyx.test.CThread. VM options: '-classic ' Launched VM Java Debug Interface (Reference Implementation) version 1.4 Java Debug Wire Protocol (Reference Implementation) version 1.4 JVM Debug Interface version 1.2 JVM version 1.4.1 (Java HotSpot(TM) Client VM, mixed mode) initSIOConnect: starting standard I/O handshake. initSIOConnect: starting SIO connect thread. Running companyx.test.CThread. Debugger connected to standard I/O socket. I have read all the documentation that I can find. Please any help would be greatly appreciated! Jaime
RE: JDEE plugins (was JUCI)
MP == Mark Pollack [EMAIL PROTECTED] writes: MP Hi, Just my two cents, I'm a lisp-wimp as I am sure are many of MP the users of JDEE, but a good Java programmer. If there was some MP way that I could write JDEE extensions in Java for at least some MP subset of plug-in functionality that would be great since I never MP seem to find the time to really learn lisp. I realize it might be MP too much to accommodate us lisp-wimps, but just keep it in mind if MP it turns out to be not such a big deal to go in this direction. One of the things I think it would be easy to do early on is providing a command that prompts for a Java interface and will code-generate the elisp functions to match up with and be able to invoke the java interface. I think a good plugin architecture for the JDE will allow non-Elispers to get along with a minimal knowledge. There could be a fair amount of automation that, given a minimal amount of initial java code, could: 1. Generate the Elisp code. 2. Package/jar everything up according to the JDEE's plugin package structure. Also, over time, it would be nice to flesh out some standard JDEE Java APIs for prompting for user input, so there would be virtually no need at all to write custom elisp! /Nick
RE: JDEE plugins (was JUCI)
PK == Paul Kinnucan [EMAIL PROTECTED] writes: [...] 4) Based on (3), it can replace direct invocations of the JVM with jde-eval calls (which should make it much faster) PK Yes. Problem with (4) is how to get the output to a compilation buffer. When I launch a new JVM process myself, I can just redirect the output to any buffer I choose; if I launch the Java portion of the plug-in from the BeanShell, the output goes to stdout, which is captured as lisp forms by the BeanShell, right? Sorry if that is a basic elisp question, but how do I redirect that output to a compilation buffer? I guess I could use that code you mentioned. I looked at the code at jde-checkstyle.el for an example but my impression is that it launches an new JVM for each invocation instead of using the BeanShell, is that correct? As a first pass it should be OK for the plugin to do the same, but then we will be missing an opportunity for code re-use. Part of what you're searching for here doesn't really exist yet, at least not in a general form. As part of the discussion for what constitutes a pure Java API for allowing plugins to interact with Emacs we would want to include this specific feature (stream text to a compilation output buffer). PK The JDEE's compile server and ant server each uses its own PK compilation-mode buffer to display output from the BeanShell. This PK is in addition to the comint (interactive user) buffer that is PK used to start up the BeanShell. The reason that it is possible to PK have multiple buffers interacting with the BeanShell is that Emacs PK allows Lisp code to specify and change dynamically the process PK output handler. The compile server and the ant server, after PK sending a Java expression to the BeanShell, temporarily replace PK the standard output handler with their own handler to handle the PK result of evaluating the expression. My intention is to write an PK eieio class called bsh-compilation-output-buffer that encapsulates PK this technique. This would make it trivial for Java plugins to PK create compilation-style buffers for handling compilation-like PK output from Java. Critical to this technique I think will be some sort of implementation of java.io.InputStream/OutputStream or java.io.Reader/Writer on the Java side which would trigger that standard output handler switch. Could we also use a separate socket for this? Java could open a server socket and Emacs could connect to it to download the compilation output and stream it to a buffer. [...] 2) Minimal to none elisp code required. I think we will have elisp-based plug-ins as well, but I expect most to be Java-based - just because most JDEE users know Java much better than they know Lisp. What would be the list of resources available to the Java code in the plug-ins? Any ideas on how to make Emacs/JDEE resources like buffers, point position, region content, files in sourcepath, etc. easily available? Maybe a basic class that they could extend? We have to define the container environment for the plug-ins. PK I'll depend on somebody else to do this. I'd be happy to take suggestions and lead up an effort to create the Java plugin API. Why don't people start listing off pieces of functionality that we can start gathering into specifications as Java interfaces. Those interfaces, after iterating on their contents could become the initial versions of that API. Finally, how do we manage different versions of common Java libraries (like XML parsers) among plug-ins? PK Good question. Maven (http://jakarta.apache.org/turbine/maven/) has its plugins declare library dependencies, and even allows you to have them downloaded for you automatically! We should have a look at the Maven codebase for ideas in that area. At a minimum it would be nice to take advantage of the library repository that's been set up already (I believe it's on ibiblio.org). /Nick
RE: JDEE plugins (was JUCI)
PK == Paul Kinnucan [EMAIL PROTECTED] writes: PK Hi, You and others have raised two related but separate issues: PK one is the need for plugin-in support and the other is a need for PK a way to extend the JDEE that requires only Java programming PK skills. My proposal addresses the first. I believe Nick Sieger's PK JUCI addresses the second. Perhaps Nick could chime in and explain PK how. So far, what I've done with JUCI allows Emacs and Java to communicate in a consistent and general way, providing a layer of abstraction above raw lisp forms printed on standard output, beanshell execution and the like. My current code in the JDEE CVS (lisp/jde-juci.el) has some very rudimentary examples (mostly unit tests), so what's there is just a shell at this point. Although it's quite easy to envision what's coming next, namely, a general interface that Java plugins could code to for receiving input and sending output, much along the lines that Nic Pottier has already started to enumerate. Let's continue to gather and take inspiration from other plugin APIs as to what sort of pieces of data need to be exchanged. Where possible, talk in terms of emacs interface objects (buffers, windows, frames, region, point, etc.) but also express them in terms of what a Java interface might look like. What are the logical groupings for retrieving certain kinds of information? What would you name an interface for fetching the current buffer, the current buffer file, the current class, etc.? From my perspective, it'll be interesting to flesh these issues out further. Following a standard API/JSR would be ideal, but if that doesn't even exist yet, it will be hard. Also, it's going to be difficult to abstract away Emacs' tried-and-true concepts like buffers, windows, etc. The API is probably going to end up having Java objects called Buffer, Window, Frame, etc. /Nick P.S. For some technical notes on JUCI, have a look at the file java/src/jde/juci/package.html in CVS, or ask me and I'll send you a copy.
RE: JDEE plugins (was JUCI)
Hi Nick,
Where possible, talk in terms of emacs
interface objects (buffers, windows, frames, region, point,
etc.) but also express them in terms of what a Java interface
might look like. What are the logical groupings for
retrieving certain kinds of information? What would you name
an interface for fetching the current buffer, the current
buffer file, the current class, etc.?
I attached the module that implements the generic Java-Emacs interface in
the jde-transmogrify package. It was done to mirror the Transmogrify Hook
interface, which I believe was derived from the JBuilder plug-in interface.
We could use it as a starting point, as it is part of a working plug-in
(in the sense of a Java-based add-on to JDEE).
The relevant methods (that Java code can use to change the Emacs
environment) are:
42: public void showReferencesSourced(IDefinition definition) {
57: public void showReferencesNonsourced(IDefinition definition) {
67: public void openFile(String sourceFileName)
78: public File[] getFiles()
90: public String getCurrentFile()
102: public String getUserInput(String prompt, String title)
108: public void displayMessage(String title, String message)
113: public void displayException(Exception e, String description) {
135: public String getText()
146: public String getLine(int lineNumber)
159: public void selectText(int startLineNumber,
177: public void selectText(int startPos, int endPos)
188: public void deSelectText()
198: public String getSelectedText()
208: public Enumeration getSelectedLines()
219: public int getCaretLineNumber()
230: public int getCaretOffset()
242: public int getCaretPos()
248: public int getSelectionStart()
254: public int getSelectionEnd()
266: public void setCaretPos(int lineNumber, int offset)
279: public void setCaretPos(int pos)
Regards,
Nascif
EmacsHook.java
Description: Binary data
Re: JDEE plugins (was JUCI)
On Wed, 19 Feb 2003, [EMAIL PROTECTED] wrote: this plugin architecture may require enough redesign to rethink the way JDE works now. One thing that seems prevalent in these thoughts is that the JDE is the central point of focus for this plugin architecture and the plugin architecture is hardwired to the JDE only. This obviously is understandable, because, many plugins are specific for enhancing IDEs. But there are plugins, ant, for instance, which are used outside of java IDEs. Would it make more sense to think of plugins as plugins to Emacs and the JDE as a client of the functionality newly present in Emacs? I'm worried that we are making the JDE an everything java server for Emacs, when shouldn't it be just a client to the elisp version of the everything java VM (where the VM might be the beanshell)? To say in a different way, it seems that Emacs should be enveloping a JVM, and supporting plugin architecture irrespective of the JDE. Then, the JDE should be utilizing this new elisp functionality. Then, to get new java functionality would be like going to http://anc.ed.ac.uk/~stephen/emacs/ell.html and getting a new cool elisp package to add to your Emacs experience. So what its written in java, just plug it in to Emacs and it has an elisp interface for you. Okay, I know, I'm probably smoking something, ... -- Galen deForest Boyer Sweet dreams and flying machines in pieces on the ground.
