Jayakrishnan Nair writes: > > Where can I find information on how to use jde-xref ? >
In the JDEE User's Guide under "Cross-Referencing Classes." Paul > -----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. >
