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. >
