Hi, You and others have raised two related but separate issues: one is the need for plugin-in support and the other is a need for a way to extend the JDEE that requires only Java programming skills. My proposal addresses the first. I believe Nick Sieger's JUCI addresses the second. Perhaps Nick could chime in and explain how.
Paul James Higginbotham writes: > <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
