Re: jdb bug and quick fix

Sorry,I didn't say anything about remove jdb from jdee.
My advice is remove jdebug.(not jdb)
There are three type of debugger in jdee,
jdb,old jdb and jdebug.

Carlos Konstanski <[email protected]> writes:
> On Fri, 9 Nov 2007, Paul Landes wrote:
>
>> Date: Fri, 9 Nov 2007 09:15:50 -0600
>> From: Paul Landes <[email protected]>
>> To: Ke Lu <[email protected]>
>> 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?
>>
>
> Thank you.  You can count me among those who would be extremely
> dismayed if jdb were removed.  What is the point of removing it?  If you don't
> like it, don't use it.  Linux is about choices.  But I assume too much; perhaps
> Ke Lu is a windows, solaris or mac user.
>
> I am willing to take part in maintaining JDEE.  Taking on the job all by myself
> would be a bit much.  Can we get a short list of folks who are
> willing to take part in a maintenance committee?
>
>>
>> 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]
>>
>
> Carlos Konstanski