Re: Why does JDEE look for tools.jar
On Mon, 2004-11-22 at 15:15, Shyamal Prasad wrote: I'm having trouble running JDEE (with both Emacs and XEmacs) on a Debian GNU/Linux system. The problem is with finding the tools.jar file. Since I'm using runtimes not licensed from Sun (sablevm, kaffe etc.) this file is missing. I don't know what the situation is with Debian and Kaffe/SableVM, but here's a recent development from the Fedora world. Fedora Core 3 now ships the following packages: java-1.4.2-gcj-compat java-1.4.2-gcj-compat-devel See http://fedora.redhat.com/docs/release-notes/fc3/x86/ I think these provide a fake tools.jar file, as well as /usr/bin/java and /usr/bin/javac. See http://www.spindazzle.org/green/index.php?p=24 Vadim
Re: Why does JDEE look for tools.jar
Suraj Acharya writes: JDE also looks for tools.jar to check if a directory is a JDK directory or not. Try creating an empty tools.jar in the lib directory of your JDK. You will be able to use the compile server, but it might let you used JDE with other jdks. The JDEE currently assumes that you are using Sun's toolset. I will look into supporting other tool sets as time permits. Paul Suraj On Mon, 22 Nov 2004 23:25:05 -0500, Matt Kurjanowicz [EMAIL PROTECTED] wrote: The tools.jar is the file that contains the compiler. This way JDEE can run the compiler directly using the classpath that JDEE sets. -Matt On Monday 22 November 2004 03:15 pm, Shyamal Prasad wrote: Hi, I'm having trouble running JDEE (with both Emacs and XEmacs) on a Debian GNU/Linux system. The problem is with finding the tools.jar file. Since I'm using runtimes not licensed from Sun (sablevm, kaffe etc.) this file is missing. Could some one explain to me (just a hint) why tools.jar is so important to JDEE? I can run beanshell without it, and I'm not sure what else might be needing it. Best regards, Shyamal PS: I read this list via the web, so I would never complain about a Cc :-) -- Matthew Kurjanowicz [EMAIL PROTECTED] CS 2110 TA College of Computing GEORGIA Institute of TECHnology
Re: Why the JDEE?
Paul == Paul Kinnucan [EMAIL PROTECTED] writes: Paul It also allows users who are, like myself, working in a Paul multilanguage environment (e.g., C/C++/Java) to use a single Paul environment for all their work. This is my primary motivation for using emacs, and JDE for java. I use many different languages. And often ones for which big flashy IDE's are not available. Besides why would I want to learn three different ways of accessing version control for instance? With Emacs it's always there, and its always the same. Paul In my view, the JDEE's greatest deficiency in this Paul regard is in debugging support. I would have to agree with this. For many years I have used Java quite happily without a debugger, and, of course, its quite feasible to do this. But recently I spent 5 months writing perl. Now this is a language which its nearly impossible to write without a debugger. Coming back to Java, I find that I miss it quite a bit. Phil
Re: Why the JDEE?
Ralph Jorre writes: I don't often use a debugger but I have found JSwat very good and I just wonder if it wouldn't be more efficient to just include some hooks so as to be able to incorporate it efficiently. Maybe this would be easier to maintain than rewriting the debug. I plan to look into this. The problem is that the task of writing an Emacs front-end to JSwat may outway the advantage of replacing JDEbug with JSwat as the backend. In other words, there already exists a Lisp frontend to JDEbug. So it comes down to whether it makes more sense for me to spend my time on creating a frontend for JSwat or fixing the problems with JDEbug. Complicating the decision is the fact that I have created a generalized object-oriented debugger frontend, based on eieio. I decided to do this because jdb and the JDEbug frontends have a lot in common, e.g., essentially the same code for stepping and setting, recording, and displaying breakpoints. The generalized frontend allows both backends to inherit any improvements to the front end. I have already ported jdb to use the generalized frontend and am in the process of porting the JDEbug frontend to the generalized front end. It is conceivable that the generalized JDEE frontend could ultimately support three backends: jdb JDEbug JSwat In fact, I would prefer this as I believe there is value in having a backend that is tuned to the JDEE plus support for alternative backends as backups or to cater to user preferences for those backends. My preference would be for somebody other than myself to take on the task of creating a JDEE frontend to JSwat's console mode. This would free me to concentrate on the generalized frontend and on fixing the JDEbug backend. Developing a JSwat frontend basically entails subclassing the JDEE's generalized debugger frontend (see jde-db-debugger class) to support JSwat's console commands. This should be a fairly straightforward task. I'd be glad to serve as a consultant to anyone who wants to undertake this project. - Paul
Re: Why the JDEE?
I had thought of this as well. Perhaps the JSwat maintainer would be interested in working on it. If you download the JSwat CVS code, you see they arleady use JDEE. See: http://home.nc.rr.com/nascifandelaine/jswat.el Paul Kinnucan [EMAIL PROTECTED] writes: Ralph Jorre writes: I don't often use a debugger but I have found JSwat very good and I just wonder if it wouldn't be more efficient to just include some hooks so as to be able to incorporate it efficiently. Maybe this would be easier to maintain than rewriting the debug. I plan to look into this. The problem is that the task of writing an Emacs front-end to JSwat may outway the advantage of replacing JDEbug with JSwat as the backend. In other words, there already exists a Lisp frontend to JDEbug. So it comes down to whether it makes more sense for me to spend my time on creating a frontend for JSwat or fixing the problems with JDEbug. Complicating the decision is the fact that I have created a generalized object-oriented debugger frontend, based on eieio. I decided to do this because jdb and the JDEbug frontends have a lot in common, e.g., essentially the same code for stepping and setting, recording, and displaying breakpoints. The generalized frontend allows both backends to inherit any improvements to the front end. I have already ported jdb to use the generalized frontend and am in the process of porting the JDEbug frontend to the generalized front end. It is conceivable that the generalized JDEE frontend could ultimately support three backends: jdb JDEbug JSwat In fact, I would prefer this as I believe there is value in having a backend that is tuned to the JDEE plus support for alternative backends as backups or to cater to user preferences for those backends. My preference would be for somebody other than myself to take on the task of creating a JDEE frontend to JSwat's console mode. This would free me to concentrate on the generalized frontend and on fixing the JDEbug backend. Developing a JSwat frontend basically entails subclassing the JDEE's generalized debugger frontend (see jde-db-debugger class) to support JSwat's console commands. This should be a fairly straightforward task. I'd be glad to serve as a consultant to anyone who wants to undertake this project. - Paul
Re: Why the JDEE?
On Fri, 21 Feb 2003, [EMAIL PROTECTED] wrote: It is hopeless for the JDEE to try to compete feature-for-feature with dedicated Java IDE's, especially commercial IDE's. Maybe to further this, create an email list called, jde-plugin, or something like it. Then, as people want to discuss this idea and try to make Emacs have an architecture to keep up with the other IDE's, you can monitor and consult on the direction but not feel compelled to answer the direct questions to this particular list. And, when questions of this sort hit the jdee list, we can point them to this particular branch of JDEE discussion. We, as users, can also feel that we won't be going against your wishes as to the focus of the jdee, and hence, the jdee mailing list itself. -- Galen Boyer
Re: Why the JDEE?
Galen Boyer writes: On Fri, 21 Feb 2003, [EMAIL PROTECTED] wrote: It is hopeless for the JDEE to try to compete feature-for-feature with dedicated Java IDE's, especially commercial IDE's. Maybe to further this, create an email list called, jde-plugin, or something like it. Then, as people want to discuss this idea and try to make Emacs have an architecture to keep up with the other IDE's, you can monitor and consult on the direction but not feel compelled to answer the direct questions to this particular list. And, when questions of this sort hit the jdee list, we can point them to this particular branch of JDEE discussion. We, as users, can also feel that we won't be going against your wishes as to the focus of the jdee, and hence, the jdee mailing list itself. I was only explaining where I intend to focus my efforts personally for the immediate feature. I welcome others working on features that interest them personally. A number of people are already doing this and are updating the JDEE CVS repository independently of myself. I would be glad to give anyone else access to the JDEE CVS repository who can demonstrate the necessary skill level and commitment to quality. - Paul
Re: Why the JDEE?
Paul, For what it's worth, I absolutely agree with you on the need for debugging support. I still follow the JDEE mailing list but I had to drop JDEE for Eclipse almost a year ago because of the lack of debugging support ... I can live with it on a small project, but on a large project (esp. when using Swing) JDEE really needs better means of debugging. Having said that, thanks for bringing JDEE to the world and it's continued enhancement. Milan On February 21, 2003 03:30 pm, Paul Kinnucan wrote: 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
Re: Why the JDEE?
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
RE: Why the JDEE?
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
Re: Why the JDEE?
I could not agree more. We love JDEE because we love emacs. Emacs will always be a better editor than any other IDE, therefore JDEE will always be better for editing then any other IDE. Throw in the compiling and debugging tools already there, and it's already an excellent tool. Hopefully people can add advanced functionality as needed, including plug-ins. I agree that debugging needs the most work, and I intend to help with that effort. Paul Kinnucan [EMAIL PROTECTED] writes: 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
RE: Why the JDEE?
Chitale, Sandip V writes: 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) This is planned. 3. storing and managing breakpoints Ditto. 4. breakpoint grouping Not sure what this is. 4. Different kinds of breakpoints i. conditional breakpoints This is really hard. It entails creating a Java expression parser to parse conditions. JDEbug has an extremely primitive parser. I started work on a JavaCC-based parser several years ago. It's source code is in the JDEE distribution. ii. actions when the breakpoints are hit Specified how? 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. I'll look into this. If it's supported by the JPDA, it should be easy to provide. v. Class loading breakpoint Ditto. - Paul
Re: Why the JDEE?
Hello Paul et al: 3. storing and managing breakpoints This is my #1 wish list. Back in the JDE 2.1.5 days I had files full of: stop in corba.hcks.Client.testMisc It was great. I never had to visit a file just to set a breakpoint. Thanks, Harold
RE: Why the JDEE?
Chitale, Sandip V writes: 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) This is planned. 3. storing and managing breakpoints Ditto. 4. breakpoint grouping Not sure what this is. For example Karmira's BugSeeker has this feature. I use it this way: 1. I group all my source based breakpoints in one group 2. I group all my exception based breakpoints in another 3. I group all JDK source based breakpoints in third group 4. I group all JDK exception based breakpoints in fourth group (At one point in time I filled this group with all the exceptions in JDK - I simply disable the group most of the time). 5. similar groups for other librariesetc. I can operate on the group as whole: 1. Delete 2. Enable 3. Disable Then depending on what kind of debugging I am doing I enable or disable the groups. There is some color coding of breakpoints markers based on the group membership also. Obviously this is one way of achieving this functionality. There may be others 4. Different kinds of breakpoints i. conditional breakpoints This is really hard. It entails creating a Java expression parser to parse conditions. JDEbug has an extremely primitive parser. I started work on a JavaCC-based parser several years ago. It's source code is in the JDEE distribution. ii. actions when the breakpoints are hit Specified how? Using customization: 1. Stop at breakpoint and/or 2. Print value of a java expression (assuming it is evaluatable) and/or 3. Stop only every third time (I guess this falls under conditional iii. method entry breakpoint (JPDA allows this) iv. method exit breakpoint I would like to be able to set these from ECB or speedbar also. 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. I'll look into this. If it's supported by the JPDA, it should be easy to provide. v. Class loading breakpoint Ditto. I also missed the following in earlier email. 1. Field access breakpoint 2. Field read breakpoint 3. Field write breakpoint Breakpoint filters : 1. Thread based 2. Package name regexp based e.g. ignore all NPEs in or.apache.* etc. - Paul
