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.
