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

Reply via email to