<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
