1

I am a C++ dev, working in java technology for about a year. Forgive my ignorance, but I have tried to search for following two questions. What is the best way to debug in console for a java application (ala gdb in good ol' C++).

  1. It seems jdb is below par.
  2. Eclipse is the way to go for its IDE. But Eclipse is a GUI and I do develop in console on unix servers. What is the best way to tame huge jave open-source frameworks. eg, camel, hibernate, spring, logback, blah, blah
Lucifer
  • 28,605
  • 21
  • 86
  • 137
everCurious
  • 145
  • 1
  • 15

3 Answers3

1

I do most of my debugging in the console.

I have found that for the majority of bugs, Java stack traces are sufficient to identify the bug and develop a fix. This of course means that it's critical to allow stack traces to be seen on the console. For most applications, I've found that it's best to allow unchecked exceptions to propagate until they terminate the thread, with a stack trace showing up in the console; unchecked exceptions should normally indicate programming errors or uncontrollable conditions where the thread should be terminated anyway.

In cases where the stack trace is not sufficient, I've found that using System.out.println() during the debugging process is actually more effective than using an interactive debugger. Having a full log of a run is for me more useful than running a debugger where I may easily step past an issue that later turns out to be important.

Warren Dew
  • 8,281
  • 3
  • 28
  • 43
  • Thanks for your comments.
    But that is more of error reporting for which exceptions shall be generated. My question is more of debugging frameworks to gain knowledge. Its frustrating to google for ages for a seemingly trivial issue and treat them as blackbox esp when frameworks are open-source. I am loosing out on a key advantage.     – everCurious Apr 18 '14 at 05:59
  • I'm thinking less of exceptions that one writes code to throw, and more about exceptions that get automatically thrown in cases of errors, like NullPointerException and IndexOutOfBoundsException. Of course, I'm not sure what kind of trivial seeming issues you are spending ages searching for information on; can you give an example? – Warren Dew Apr 18 '14 at 06:13
  • One issue was configuring properties using spring. there were multiple ways elaborated in web articles. Articles were written during different times which had different spring versions. Some of the proposed solutions didnt work. If I had access to debugging tools, I could have easily looked up the source and resolved intelligently. – everCurious Apr 18 '14 at 06:22
  • In principle, the way to resolve issues with libraries is to follow the official documentation carefully when writing the code calling them. Usually Java libraries are pretty good about having solid documentation because of the ease of use of Javadoc, but I agree Spring configuration seems to be a bit of an exception. While I'm not as sanguine as you about the effectiveness of stepping through Spring library code, you should be able to download the source jar and view it in whatever way you want, though you may need to use and IDE to step through it. – Warren Dew Apr 18 '14 at 06:38
  • Thanks @Warren, I am not very positive about stepping through source-code. But, hey, at least thats an option due to open source nature. Also, documentation is usually good with spring but they cannot contain answers to alot of questions that arise during adoption. At least, thats been my experience. Also, using IDE again brings me back to the first question, can I not use the unix console env to debug for java (like I can for C++). Why is that a blasphemy in java world ? – everCurious Apr 18 '14 at 06:43
  • I don't think it's a blasphemy; I think it's just that there's a lot less demand for it in the Java world. When gdb was developed, C++ was used in many embedded systems that were too small to support an IDE; Java has always required at least a JVM, so aside from the fact that stack traces reduce the need for running a debugger, IDEs were less likely to be unavailable as well. – Warren Dew Apr 18 '14 at 06:56
0

Wat is the problem in setting up the project in eclipse IDE, you can always get the source code and set up your workspace??

Using sysout is great for small java programs but as the code grows or for big application (according to my understanding you plan to debug something big :P) it would really be a headache placing all those sysout and then removing them once you are done with the debugging. I would suggest you to set up your own workspace by choosing 'import existing project in workspace' option of IDE, though it would be tiring first but will help you in long run.

Bazooka
  • 35
  • 6
0

I would say that there is no need for such a tool, because Java supports remote debugging.
You need to start your (server) JVM with remote debugging enabled - this will work for newer JDKs: 

-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005

After that you connect to it from the IDE, and set breakpoints or conditional breakpoints wherever you like.

See this question for more details

Also, this is a personal preference, but I would say that IntelliJ IDEA is the way to go as far as Java IDEs go.

Community
  • 1
  • 1
Yevgeny Krasik
  • 171
  • 2
  • 8
  • Thanks for your response. My question would make sense for someone migrating from C++ to java. In C++, gdb (console-based) rules the roost. And its such a pleasure to just not having to install an IDE to debug. IDE installation should be optional (that too, mainly for development). For debugging on a mature and stable platform such as java, I would assume debugger to be an independent component and not integrated with IDE. Also, I think JDB is such an attempt but its woefully inadequate in comparison with GDB. – everCurious Jun 20 '15 at 09:30