I agree, although I personally don't really care for #4. I would add that displaying variables on a large object tree may be extremely slow if data are being sent between emacs and java.
Milan On February 21, 2003 03:41 pm, Chitale, Sandip V wrote: > I agree with you. > > In terms of features in debugger I would like to see - > > 1. fast update to different views > 2. better variables view (I would like to suggest Java based GUI for > this i.e. a treetable) > 3. storing and managing breakpoints > 4. breakpoint grouping > 4. Different kinds of breakpoints > > i. conditional breakpoints > ii. actions when the breakpoints are hit > iii. method entry breakpoint (JPDA allows this) > iv. method exit breakpoint > > a. normal exit > b. abnormal exit (exception) > c. ability to see return value on the stack (even if it > was not > stored in some local variable). I am not sure if JDPA > allows this. > v. Class loading breakpoint > > > > > Just my wish list. > > -sandip > > > -----Original Message----- > > From: Paul Kinnucan [mailto:[EMAIL PROTECTED] > > Sent: Friday, February 21, 2003 12:30 PM > > To: [EMAIL PROTECTED] > > Subject: Why the JDEE? > > > > > > Dear JDEE Users, > > > > A number of recent threads have alluded to the need for the > > JDEE to keep pace, featurewise, with the competition, e.g., > > Eclipse and JBuilder. > > > > I'd like to present my perspective on this issue as the > > JDEE's lead developer and maintainer. > > > > It is hopeless for the JDEE to try to compete > > feature-for-feature with dedicated Java IDE's, especially > > commercial IDE's. The reason is that the pure Java IDEs do > > not face the difficult skills and architectural constraints > > than the JDEE development team faces, e.g., JDEE development > > requires both Emacs Lisp and Java skills and is constrained > > to standard I/O for interprocess communications. > > > > Why then bother with the JDEE? Because it allows Emacs users > > to use Emacs to develop Java code. Put another way, the > > reason for choosing the JDEE will always be Emacs and not the > > other way around. The JDEE allows Emacs users to make the > > transition to Java development without having to learn > > another environment. It also allows users who are, like > > myself, working in a multilanguage environment (e.g., > > C/C++/Java) to use a single environment for all their work. > > > > Where then should the JDEE development team focus its efforts. > > The focus should be on those features that best > > ensure that a decision to use Emacs for Java development > > does not entail a loss of productivity compared to what other > > environments afford. In my view, the JDEE's greatest > > deficiency in this regard is in debugging support. Therefore, > > it is my intention to focus my efforts personally in this > > area with the goal of providing the JDEE ASAP, not with the > > best debugger available, but at least one that does the > > basics well and reliably. > > > > Until then, other features that have been mentioned recently, > > such as a plugin architecture and syntax errors on the fly, > > will move forward only in so far as others work on them. > > > > Regards, > > > > Paul