Re: Couple of ideas
Sandip, I'd be very interested in seeing features such as preventing warning of potential errors in the code. Thanks for contributing your ideas and experiments with the JDE community! Do you have ideas of what other errors could be detected automatically? I could only think about unbalanced parenthesis. Maybe other syntaxic error could be detected by syntaxic parser bundled with the JDE? Other ideas could possibly be obtained from java code audit tools such as JTest (http://www.parasoft.com/products/jtest/) but I think they work mainly on code which compiles. Consequently, error/warning they submit are maybe less interesting during coding, but maybe in a later step? There are such things as warning about missing code statement for a stream... Regards, Guillaume. > Basically what I am trying to suggest is to take the JDE > to the further level where the syntax/symantic errors > shown like in MSWord (spelling and grammatical errors). > > Also has anyone heard of Harmonia project at Berkeley - > http://www.cs.berkeley.edu/~harmonia/ > and its integration with emacs ? >
Re: more on testing JDEbug
At 09:32 PM 4/22/2001 -0700, you wrote: > >: This is very helpful. Is this true of both Linux and Windows or are you >: able to test only Linux? > >Linux only - I would've tested Solaris too but my company moved to a new >office over the weekend and the network isn't back up yet. I realized that I commented out the setPriority line with a lisp ;; comment prefix so that I effectively did not comment it out. Sorry. The next release will have the setPriority really commented out. I just uploaded to the JDE CVS repository a new version of jde-dbo.el that fixes some problems with watchpoints. Specifically, it now updates the locals buffer and the stack menu when the debuggee process stops at a watchpoint. I am working on changes in jde-bug.el that will cause the watchpoint to default to the field at point in the source buffer. Also I have decided to make suspend all the default suspension policy as I think most people will want the program to stop when a field is accessed or modified. - Paul
Re: JDEbug problem
At 08:49 PM 4/22/2001 -0400, [EMAIL PROTECTED] wrote: >Hi there, >System : >- Suse 7.0 Linux >- Emacs 20.7.1 >- java version "1.3.0" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0) > Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-2623 (JIT > enabled: jitc)) >- prj.el is attached JDE version? *JDEbug* buffer ? Please file a complete problem report. - Paul
JDEbug problem
Hi there,
System :
- Suse 7.0 Linux
- Emacs 20.7.1
- java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-2623 (JIT enabled: jitc))
- prj.el is attached
Problem :
First I set a breakpoint in the ctor of my main class. Then I start the Debuger
(JDEbug->Processes->Start Debuger) and finally start to debug (JDE->Debug App) I get
the following situation :
*** Debugger Output for Process rj.pipeline.Pipeline(17) ***
vm started...
All threads suspended...
Launch command line:
java -classpath ~/Development/source/ rj.pipeline.Pipeline
Emacs connected to standard IO port 2351 for process rj.pipeline.Pipeline.
Launched VM Java Debug Interface (Reference Implementation) version 1.3
Java Debug Wire Protocol (Reference Implementation) version 1.0
JVM Debug Interface version 1.0
JVM version 1.3.0 (Classic VM, J2RE 1.3.0 IBM build cx130-2623 (JIT disabled))
initSIOConnect: starting standard I/O handshake.
initSIOConnect: starting SIO connect thread.
Debugger waiting for Emacs to connect to app SIO port 2351.
Setting breakpoint at line 89 in Pipeline.java.
Debugger connected to standard I/O socket.
Running rj.pipeline.Pipeline.
Closed transport for application's standard output.
rj.pipeline.Pipeline process ended.
vm disconnected...
I cannot see any error message in this text, so I am wondering why I cannot debug.
TIA
Ralph
__
Get your own FREE, personal Netscape Webmail account today at
http://webmail.netscape.com/
(jde-set-project-name "default")
(jde-set-variables
'(jde-gen-session-bean-template (quote ("(jde-import-insert-imports-into-buffer (list
\"javax.ejb.*\"
\"java.rmi.RemoteException\"))" "(jde-wiz-update-implements-clause \"SessionBean\")"
"'> \"public void ejbActivate() throws RemoteException {\"'>'n \"}\"'>'n
'>'n" "'> \"public void ejbPassivate() throws RemoteException {\"'>'n \"}\"'>'n
'>'n" "'> \"public void ejbRemove() throws RemoteException {\"'>'n \"}\"'>'n '>'n" "'>
\"public void setSessionContext(SessionContext ctx) throws
RemoteException {\"" "'>'n \"}\"'>'n '>'n" "'> \"public void unsetSessionContext()
throws RemoteException {\"'>'n
\"}\"'>'n '>'n'>")))
'(jde-gen-beep (quote ("(end-of-line) '&"
"\"Toolkit.getDefaultToolkit().beep();\"'>'n'>")))
'(jde-which-method-format (quote ("[" jde-which-method-current "]")))
'(jde-run-classic-mode-vm nil)
'(jde-javadoc-gen-nodeprecatedlist nil)
'(jde-which-method-max-length 20)
'(jde-imenu-include-classdef t)
'(jde-javadoc-gen-link-online nil)
'(jde-gen-code-templates (quote (("Get Set Pair" . jde-gen-get-set) ("toString
method" . jde-gen-to-string-method) ("Action Listener" . jde-gen-action-listener)
("Window Listener" . jde-gen-window-listener) ("Mouse Listener" .
jde-gen-mouse-listener) ("Mouse Motion Listener" . jde-gen-mouse-motion-listener)
("Inner Class" . jde-gen-inner-class) ("println" . jde-gen-println) ("beep" .
jde-gen-beep) ("property change support" . jde-gen-property-change-support) ("EJB
Entity Bean" . jde-gen-entity-bean) ("EJB Session Bean" . jde-gen-session-bean
'(jde-gen-cflow-else (quote ("(if (jde-parse-comment-or-quoted-p)" "'(l \"else\")"
"'(l '> \"else \"" "(if jde-gen-k&r " "()" "'>'n)" "\"{\"'>'n'>'r'n" "\"} // end of
else\"'>'n'>)" ")")))
'(jde-make-args "")
'(jde-javadoc-gen-destination-directory "JavaDoc")
'(jde-mode-line-format (quote ("-" mode-line-mule-info mode-line-modified
mode-line-frame-identification mode-line-buffer-identification " "
global-mode-string " %[(" mode-name mode-line-process minor-mode-alist "%n" ")%]--"
(line-number-mode "L%l--") (column-number-mode "C%c--") (-3 . "%p")
(jde-which-method-mode ("--" jde-which-method-format "--")) "-%-")))
'(jde-mode-abbreviations (quote (("ab" . "abstract") ("bo" . "boolean") ("br" .
"break") ("by" . "byte") ("byv" . "byvalue") ("cas" . "cast") ("ca" . "catch") ("ch" .
"char") ("cl" . "class") ("co" . "const") ("con" . "continue") ("de" . "default")
("dou" . "double") ("el" . "else") ("ex" . "extends") ("fa" . "false") ("fi" .
"final") ("fin" . "finally") ("fl" . "float") ("fo" . "for") ("fu" . "future") ("ge" .
"generic") ("go" . "goto") ("impl" . "implements") ("impo" . "import") ("ins" .
"instanceof") ("in" . "int") ("inte" . "interface") ("lo" . "long") ("na" . "native")
("ne" . "new") ("nu" . "null") ("pa" . "package") ("pri" . "private") ("pro" .
"protected") ("pu" . "public") ("re" . "return") ("sh" . "short") ("st" . "static")
("su" . "super") ("sw" . "switch") ("sy" . "synchronized") ("th" . "this") ("thr" .
"throw") ("throw" . "throws") ("tra" . "transient") ("tr" . "true") ("vo" . "void")
("vol" . "volatile") ("wh" . "while"
'(jde-imenu-enable t)
'(jde-compile-option-verbose nil)
'(jde-db-option-heap-size (quote ((1 . "megabytes") (16 . "megabytes"
'(jde-bug-debugger-host-address "linux.local")
Re: more on testing JDEbug
In message <[EMAIL PROTECTED]>, eric writes: : : Yes, the beta10 fix yielded a working debugger in both emacsen. There : were no changes to code or to the number of ambient processes between : the upgrade, and I repeated the exercise with a downgrade (didn't work) : and a re-upgrade (worked). But also keep in mind the importance of : upgrading the VM itself from 1.3 => 1.3.1. Correction - I retraced my steps and realized that I hadn't tested beta9 with VM 1.3.1 and xemacs. I have done so and it *does* work, so it would seem that the real problem is in VM 1.3.0, which is known to have JPDA issues. To summarize beta9beta10 --- FSF/1.3GOOD*BAD* Xemacs/1.3 BAD* BAD* FSF/1.3.1 GOOD GOOD Xemacs/1.3.1 GOOD GOOD * results were seemingly random - sometimes it works, sometimes it doesn't. In these cases the GOOD/BAD indicator show what happened most of the time. Apologies for the confusion, Eric "obviously not a QA whiz on TV or anywhere else"
Re: more on testing JDEbug
In message <[EMAIL PROTECTED]>, Paul Kinnucan write
s:
: Eric, I am a little confused. Are you saying that my thread priority "fix"
: in beta10 is an improvement? If so, that is very interesting. I believer
: there other debugger threads that JDEbug sets to max priority (actually
: MAX_PRIORITY-1). I've never understood why the code, which was written by a
: Sun summer intern, was setting the priority of these threads. However,
: since the intern was working as a member of the JPDA team, I assumed he had
: access to inside information so I was reluctant to touch his code in this
: area. Recently, however, I have been reading Holub's "Taming Java Threads"
: and found his discussion of how thread scheduling differs drastically from
: platform to platform enlightening and horrifying. Holub's advice is
: basically just not to monkey with thread prioirty since you can't set
: priorities in a platform-independent way. So I'm inclined to comment out
: all the set-priority calls in the JDEbug code.
Yes, the beta10 fix yielded a working debugger in both emacsen. There
were no changes to code or to the number of ambient processes between
the upgrade, and I repeated the exercise with a downgrade (didn't work)
and a re-upgrade (worked). But also keep in mind the importance of
upgrading the VM itself from 1.3 => 1.3.1.
In my experience Holub is exactly right. In VMs (linux) that implement
threading as processes, the scheduler in the kernel has an opportunity
(indeed, an obligation) to control "threads" in a way that just doesn't
happen when threading is implemented within a single process.
I was curious, so I wrote a little priority test in which I start two
threads, one with MAX_PRIORITY and the other with MIN_PRIORITY.
Each thread has an instance of a Runnable whose run method looks like
this:
long runcount = 0L;
public void run() {
try {
while (true) {
System.out.println(Thread.currentThread().toString() + ":" +
runcount++);
} // end of while (true)
} catch (Exception e) {
e.printStackTrace();
} // end of try-catch
}
Since these runnables are just competing for CPU time (and System.out, of
course), you'd expect the one that belongs to the Thread with MAX_PRIORITY
to eventually end up with a much higher runcount.
Curiously, my results are exactly the opposite: if left to run ~10,000
times, the MIN_PRIORITY thread ends up about 1,000 iterations ahead.
I ran the test a few times, for different durations, and MIN_PRIORITY
always got more cycles.
I conclude from this (completely unscientific) test that you and Holub
are exactly right - setting thread priorities isn't worth the trouble,
because of the inherent OS dependencies in scheduling.
As to trusting the inside information of Sun's summer intern - well
The JDK has quite a few classes that were probably written by well
meaning, but poorly mentored summer interns. The Observable/Observer
classes are a disaster because of the requirement that you sublass
Observable to use them (observable should've been an interface and Sun
should've provided an "observable support" class to which implementors
could delegate, a la property change support). java.text.BreakIterator
is terrible because it cannot be extended to introduce more intelligent
segmentation rules, which is why IBM had to rewrite it. Making Stack
a subclass of Vector is pretty awful too, since you end up with a data
structure that can be altered in all kinds of un-stack-like ways if
people aren't paying attention.
At any rate, it's very easy to criticize someone else with the benefit
of 20/20 hindsight (and it's fun too, as Homer Simpson once said, ha ha),
but suffice it to say that I'm not exactly shocked that a javasoft insider
would flub some multithreading code - it's still darn hard to get right,
even if you're spending a summer in the Silly Valley.
Eric
Re: more on testing JDEbug
At 08:47 AM 4/22/2001 -0700, Eric D. Friedman wrote: > >Using FSF emacs (will try xemacs shortly) and 2.2.7b10, I was able to >debug the test code I wote about earlier. > > >I was interested to learn that previous releases of JDEbug had been >setting a debug thread to max priority; I'm testing on linux and on that >platform native threads are implemented as processes. I did notice >(but did not report) that emacs became quite sluggish when I started >JDEbug, which might meant that it was having trouble getting CPU cycles. >You may recall that earlier yesterday, with the same release, I was >able to debug my application. At that time I had many more processes >running concurrently on my system than I did when I could not debug later >that same day. It worked, in other words, when the scheduler wouldn't >let the CPU be monopolized by the MAX_PRIORITY thread, and hung up when >there weren't any non-emacs/jde processes around to challenge "mad max." > > Eric, I am a little confused. Are you saying that my thread priority "fix" in beta10 is an improvement? If so, that is very interesting. I believer there other debugger threads that JDEbug sets to max priority (actually MAX_PRIORITY-1). I've never understood why the code, which was written by a Sun summer intern, was setting the priority of these threads. However, since the intern was working as a member of the JPDA team, I assumed he had access to inside information so I was reluctant to touch his code in this area. Recently, however, I have been reading Holub's "Taming Java Threads" and found his discussion of how thread scheduling differs drastically from platform to platform enlightening and horrifying. Holub's advice is basically just not to monkey with thread prioirty since you can't set priorities in a platform-independent way. So I'm inclined to comment out all the set-priority calls in the JDEbug code. >So, now that I can do my `basic' debug test, I'm trying some of >the debugging features that I haven't used before and am having new >problems. :-) > >I attempted to `watch' the fields in my test class and entered the fully >qualified classname `test.Main' into the appropriate text entry field. >I got the following error: > >Error: unable to enable watch request. > Reason: '-sp' not understood: use either 'for_access' or 'for_modification'. > >in the *JDEbug* buffer, this corresponds to the following failed instruction: > >JDE> 1 10 watch test.Main for_modification -sp none > >(jde-dbo-command-error >10 "'-sp' not understood: use either 'for_access' or 'for_modification'") > Thanks. I'll look into this right away. I really appreciate your detailed and highly informed feedback, Eric. - Paul
Re: more on testing JDEbug
Now I upgraded to jdk 1.3.1 RC-1 and my test case works with xemacs. The release notes for jdk 1.3.1 say that there were problems with the JPDA in 1.3 + hotspot, and I know that Optimizeit didn't work with hotspot VMs before 1.3.1, so perhaps JDEbug is a victim of the same bugs? At any rate, I can now debug in both emacsen. Hooray for me! Xemacs has the same problem as FSF emacs when it comes to watching for access: the debugger doesn't understand a command argument `-sp.' Eric In message <[EMAIL PROTECTED]>, eric writes: : : In message <[EMAIL PROTECTED]>, "Eric D. Friedman" > w : rites: : : : : Using FSF emacs (will try xemacs shortly) and 2.2.7b10, I was able to : : debug the test code I wote about earlier. : : OK, I tried xemacs and it does *not* work. Using top, sorted by : CPU usage, I see several java processes (which represent threads on : linux), all of which are inactive. Is it possible there's a thread : synchronization issue? : : I'm doing this in a `vanilla' setup. That is, : `xemacs -q -l just-enough-lisp-to-load-jde-beta.el path/to/my/test/Main.java' : : Eric :
Re: more on testing JDEbug
In message <[EMAIL PROTECTED]>, "Eric D. Friedman" w rites: : : Using FSF emacs (will try xemacs shortly) and 2.2.7b10, I was able to : debug the test code I wote about earlier. OK, I tried xemacs and it does *not* work. Using top, sorted by CPU usage, I see several java processes (which represent threads on linux), all of which are inactive. Is it possible there's a thread synchronization issue? I'm doing this in a `vanilla' setup. That is, `xemacs -q -l just-enough-lisp-to-load-jde-beta.el path/to/my/test/Main.java' Eric
more on testing JDEbug
Using FSF emacs (will try xemacs shortly) and 2.2.7b10, I was able to debug the test code I wote about earlier. I was interested to learn that previous releases of JDEbug had been setting a debug thread to max priority; I'm testing on linux and on that platform native threads are implemented as processes. I did notice (but did not report) that emacs became quite sluggish when I started JDEbug, which might meant that it was having trouble getting CPU cycles. You may recall that earlier yesterday, with the same release, I was able to debug my application. At that time I had many more processes running concurrently on my system than I did when I could not debug later that same day. It worked, in other words, when the scheduler wouldn't let the CPU be monopolized by the MAX_PRIORITY thread, and hung up when there weren't any non-emacs/jde processes around to challenge "mad max." So, now that I can do my `basic' debug test, I'm trying some of the debugging features that I haven't used before and am having new problems. :-) I attempted to `watch' the fields in my test class and entered the fully qualified classname `test.Main' into the appropriate text entry field. I got the following error: Error: unable to enable watch request. Reason: '-sp' not understood: use either 'for_access' or 'for_modification'. in the *JDEbug* buffer, this corresponds to the following failed instruction: JDE> 1 10 watch test.Main for_modification -sp none (jde-dbo-command-error 10 "'-sp' not understood: use either 'for_access' or 'for_modification'") Eric
Re: error during text edit of java files
Well, I solved my problem. It's not clear to me why I needed this as I see no documentation confirming what I did. FYI, I did the following: First I made sure I had _all_ the Xemacs packages installed as that had bitten me in the past. Problem still existed. Then I add the following "require" statements: (require 'timer) (require 'regexp-opt) (require 'jde) Now everything seems to work fine. At least I can edit, etc., which is where I wanted to be. Joe > > At 04:34 PM 4/20/01 -0400, Joe Berry wrote: > > >> In-Reply-To: <3AE015DF.4828.623960@localhost> > > >> Have you installed the fsf-compat package ? There you'll find > > >> timer.el with the required definition. > > >> > > >> Darren > > >> > > > > > >It was a nice try. Indeed, I did not have fsf-compat installed. > > >Installed it, no difference. I did solve the problem temporarily at > > >least > > > by simply going back to jde 2.2.1. No other changes, still using the > > >latest of semantic. > > > > Please note that JDE 2.2.6 works only with the version of semantic before > > 1.3.3. > > > > I suggest upgrading to JDE 2.2.7beta9. It is essentially a release > > candidate for 2.2.7. > > > > - Paul > > > > > Paul, > > Thank you for assistance and help. I downloaded that version (byte > compiled it per the makefile -- ended up w/18 dot-elc files out of 28 > dot.el files). When I brought up Xemacs (ver 21.1, patch 13), I got the > following error: > > "error in init file: Symbol's function definition is void: regexp-opt". I > found regexp-opt defined in jde-java-font-lock.el but beyond that, I am > stuck. > > Thanks again, > Joe > --- > Joe Berry > [EMAIL PROTECTED] > AIM "joe topshot" > Yahoo Msgr "joetopshot" > Baltimore, MD > --- Joe Berry [EMAIL PROTECTED] AIM "joe topshot" Yahoo Msgr "joetopshot" Baltimore, MD
RE: bug in writing prj.el files
Hi Nick, Thanks for the quick fixes. I will include them in the next release (2.2.7beta10). - Paul
Re: bug in writing prj.el files
Hello Nick, : I've seen this too and it looks like a bug in the code I contributed. : Please try the attached jde.el (gzipped) and let me know if it fixes the : problem. Your patched jde.el fixes the double quote problem in setting jde-db-debugger. It also fixes the same problem when setting jde-global-classpath, jde-db-source-directories and jde-db-option-classpath. Thanks, Eric
RE: bug in writing prj.el files
> From: Paul Kinnucan [mailto:[EMAIL PROTECTED]] > Sent: Saturday, April 21, 2001 10:38 PM > Subject: Re: bug in writing prj.el files > > > Hi Eric, > > Yes, I have seen this double quote phenomenon myself. Must be a regression > error in the many changes to the project code in the last several beta > releases. I'll look into it. > > - Paul > I've seen this too and it looks like a bug in the code I contributed. Please try the attached jde.el (gzipped) and let me know if it fixes the problem. I also fixed two other problems: - the `jde-log-msg' function uses `save-match-data'; this is a behind the scenes function and it should not disturb the match data - `read-file-name' in `jde-save-project' uses default-directory as the default filename. Previously if saving a new project from a java source file, accepting the default (pressing enter) to the "Save in directory:" prompt would return the java file name rather than its directory. /Nick jde.el.gz
ANN: JDE 2.2.7beta10 available at ...
http://jde.sunsite.dk/ JDE 2.2.7beta10 *** * PLEASE READ * *** * * * This release requires semantic 1.3.3, * * speedbar 0.13 (or later), and eieio-0.15 (or later). You* * can obtain all three packages at* * http://cedet.sourceforge.net* * * * This release also requires elib 1.0 or later. * * Your can obtain elib at the JDE web site in compressed * * tar (http://sunsite.auc.dk/jde/elib.tar.gz) or * * zip (http://sunsite.auc.dk/jde/elib.zip) format.* * * *** * Bug fix: JDE no longer overwrites local version of after-change-functions. Thanks to David Ponce. * The following changes are stabs in the dark at trying to solve the JDEbug application launch hangup problem that some users experience. - This release sets a limit (15 seconds) to the time that JDEbug waits for Emacs to connect to the socket used to interface Emacs to the standard I/O of the debuggee process. Some users find that JDEbug hangs when trying to launch a debuggee application. The hang appears to occur in the process of setting up the debuggee I/O interface. If the hangup is caused by Emacs being unable to connect to the SIO socket, this should at least allow the debug session to continue, though without the standard I/O interface. - JDEbug no longer sets the priority of the thread that reads debuggee standard input from Emacs. Previously JDEbug set the priority of this thread to the highest allowed. There is no input from Emacs on app launch so the read operation performed by this thread blocks. Perhaps setting it to top priority leads to a deadlock on some systems. * Bug fixes to project file facility contributed by Nick Sieger: - Project files no longer quote variable values twice. - Save project command no longer incorrectly attempts to use path of a file in the project root directory for the path of the directory.
Re: debugging JDEbug
At 01:43 PM 4/21/2001 -0700, you wrote: > >I'm pleased to report that I was able to successfully and repeatably >build,run,debug using JDE 2.2.7b9, XEmacs, and sun's JDK 1.3 for Linux. > Hi Eric, Regarding the *messages* buffer, this buffer is called the message log (or something like that) in XEmacs. There is a command show-message-log (or something like that) in XEmacs. Maybe some XEmacs user can clear this up. I am Emacs user so the JDEbug messages tend to reflect Emacs terminology. It never ceases to amaze me that the XEmacs designers would rename and bury such a critical buffer. What were they thinking? - Paul
Re: bug in writing prj.el files
Hi Eric,
Yes, I have seen this double quote phenomenon myself. Must be a regression
error in the many changes to the project code in the last several beta
releases. I'll look into it.
- Paul
At 01:09 PM 4/21/2001 -0700, Eric D. Friedman wrote:
>
>I'm doing some testing of the 2.2.7b9 release. I decided to strip my
>environment to the bare essentials and proceed incrementally, just as
>someone who'd never used JDE before would do. Doing this right involves
>re-starting xemacs over and over, so it's quite time consuming, but it
>has been enlightening. Regrettably I think of no way to roll these
>operations up into a regression suite, since they generally involve
>mousing around in emacs.
>
>At any rate, I just uncovered a subtle bug in code that writes prj.el
>files - it prevents you from configuring the jde-bug-debugger setting.
>
>Steps to repeat this:
>
>1) I removed everything jde-related from my .emacs (after backing it up,
>of course)
>
>2) I created a project with a single source file and set about configuring
>JDE to build/run/debug this project.
>
>3) At no point do I save settings to my .emacs; instead, I set them and
>then save them to a prj.el file (C-c C-v C-p).
>
>4) After configuring jde-bug-debugger to use JDEbug, saving the prj.el
>file and restarting, the JDEbug menu does not show up. Attempting to
>use JDE->Debug App yields an error about `quote' not being a valid debugger.
>
>Sure enough, the prj.el file looks like this:
>
>(jde-project-file-version "1.0")
>(jde-set-variables
> '(jde-run-executable-args (quote ("-find build.xml" "run")))
> '(jde-make-args "-find build.xml")
> '(jde-db-source-directories (quote (quote ("/usr/java/jdk1.3/src"
>"~/src/ICU/src"
> '(jde-build-use-make t)
> '(jde-run-executable "ant")
> '(jde-db-option-classpath (quote ("~/src/ICU/classes")))
> '(jde-global-classpath (quote (quote ("~/src/ICU/lib/icu4j.jar"
>"~/src/ICU/classes"
> '(jde-make-program "ant"))
>
>
>Note the line that says:
> '(jde-db-source-directories (quote (quote ("/usr/java/jdk1.3/src"
>"~/src/ICU/src"
>;; note double (quote (quote))
>
>Now, if I delete this line from prj.el, restart xemacs, reset the
>jde-bug-debugger and save it to my .emacs file, the correct line is
>inserted, and the JDEbug menu appears on subsequent restarts.
>
>'(jde-db-debugger (quote ("JDEbug" "" . "Executable")))
>;; note single (quote)
>
>I imagine that most people do not change debuggers from project to project,
>but this is still not the preferred behavior.
>
>Eric
