RE: jdb bug and quick fix

Hi Paul,

I proposed removing JDEBug about a year ago. It is a bear to maintain,
unreliable, and there are better alternatives (JSWAT?) that could be
Integrated with JDEE. There was a lot of discussion and the consensus
was that JDEBug should be removed.

Paul K.

> -----Original Message-----
> From: Paul Landes [mailto:[email protected]]
> Sent: Friday, November 09, 2007 10:16 AM
> To: Ke Lu
> Cc: [email protected]
> Subject: Re: jdb bug and quick fix
> 
> We should at least take a poll as to who might be using a feature
> before we just start removing things.
> 
> Have we asked who might be willing to maintain it first?
> 
> 
> Ke Lu writes:
>  > Carlos Konstanski <[email protected]> writes:
>  >
>  > > I prefer jdb over jdebug because jdb has enough functionality for
99%
>  > > of my debugging needs, and less gizmos and knobs in the way.
(Jdebug
>  > > is indespensible for some situations.)  But there is a bug that
>  > > affects code-stepping in jdb.  You can step through code, but the
>  > > pointer in the left gutter of the source buffer cannot track the
>  > > current line because of a stringp type error.  The error occurs
> during
>  > > the routine for finding the source buffer.  Here's the quick fix:
>  > >
>  > > In jde-util.el, the function (jde-find-class-source-file) has
these
> as
>  > > the first 2 lines:
>  > >
>  > >   (let* ((verified-name (jde-parse-class-exists class))
>  > >          (outer-class (jde-remove-inner-class verified-name))
>  > >
>  > > This would be good if (jde-parse-class-exists) returned a string,
but
>  > > it returns a boolean instead.  The call to
(jde-remove-inner-class)
>  > > throws a '(type stringp nil) error as a result.  Change the code
to:
>  > >
>  > >   (let* ((verified-name (jde-parse-class-exists class))
>  > >          (outer-class (jde-remove-inner-class class))
>  > >
>  > > `class' is the passed-in string argument to
>  > > (jde-find-class-source-file).  This is the quick fix.  It seems
to
>  > > work like it needs to.  But this makes the logical flow in this
>  > > function less than ideal.  If we're going to call
>  > > (jde-parse-class-exists) to validate the input, we should do
> something
>  > > with that validation before doing more stuff, or fail gracefully.
>  > > Something like:
>  > >
>  > >   (if (jde-parse-class-exists class)
>  > >     (let ((outer-class (jde-remove-inner-class class)))
>  > >       (do-stuff)
>  > >       ...)
>  > >     (signal-no-src-found class))
>  > >
>  > > I will try to spend some time refactoring this function and
> submitting
>  > > it for review.
>  > >
>  > > Carlos Konstanski
>  > It seems jdee will be moved to sourceforge this weekend.
>  > I agree the jdebugger is not too stable to use and
>  > I advice to remove it in the future.
>  > Another problem is:
>  > jdb in jdee can't work well when The user.language is not en.
>  > My advice is:
>  > if it is difficult to parse muti-lanuage msg of jdb's output,
>  > Please set -J-Duser.language=en to jdb options by hard coding,
>  > (including options of nomal debug, attach to socket and attach to
share
> memory)
>  >
> 
> 
> --
> Paul Landes
> [email protected]