Where can I find information on how to use jde-xref ?

-----Original Message-----
From: Andrew Hyatt [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, September 03, 2003 10:03 PM
To: Nascif Abousalh-Neto
Cc: [EMAIL PROTECTED]
Subject: Re: Refactoring with JDE?

On Wednesday, September 3, 2003, at 07:19  PM, Nascif Abousalh-Neto 
wrote:

> Good point. What do you think should be the way to go with support for
> refactorings in JDE? I can see three major directions:
> 1) Expanding on the jde-xref functionality
> 2) Using the new semantic 2.0 - assuming it has all the necessary 
> functionality
> 3) Use a Java-based backend or C-based, like Transmogrify or 
> xrefactory.
>
> I think that using an approach similar to the JDE compile server, 
> which keeps
> an instance of the java compiler running at all times, the Java 
> approach may be
> feasible in terms of performance. Then again I don't know how 
> Lisp-based grammars
> compare in terms of speed and memory usage with Java-based ones.
>
>

I would think using semantic 2.0 is what we would want.  From Paul's 
earlier email, I think he also is waiting on this.   If semantic does 
not replicate the jde-xref functionality, we can change jde-xref to 
work on source files rather than class files by using semantic 2.0 to 
do the parsing.  I'm certain it will be slower than what we have now, 
but it might be worth it.

If we don't want to wait for semantic 2.0 we can implement some simple 
refactorings that use that functionality such as "rename method" with 
jde-xref.   I had previously worked on such a system for doing 
refactorings, but ran up against a problem where I wasn't sure whether 
we should update the xref db based on the new refactoring or not.  It's 
one of the strange issues that arise from us parsing class files 
instead of source file.

Using a third party Java-based backend might be easiest, but I'm afraid 
that such a loose integration wouldn't give us many of the cool 
features we would want.  My personal view, that is not shared by many I 
fear, is that we should do as much as humanly possible in elisp.   The 
more we do in elisp, the faster and better integrated it will be.

Reply via email to