anyone have any experience using this? if so, is it worth while?
3 Answers
I just used jdb for the first time yesterday and am really pleased with the results. You see, I program in Eclipse on my laptop, then deploy to a VM to make sure the whole shebang still works. Very occasionaly, I'll have to work on something that gets executed standalone, as a commandline. These things sometimes need debugging.
This has always been a problem, because I don't want to go to the trouble of installing Eclipse on the VM (it's slow enough already!), yet I don't know of an easy way to get it to connect to my commandline-running class before it finishes running.
jdb to the rescue! It works a treat - small and functional, almost to the point where it is bare... this forces you to apply your mind more than you apply the tool (like I said here).
Make sure to print out the reference (solaris, windows, java 1.5 - I think they're all about the same, really) and have your source code open and browsable on your second screen. I hope you have a second screen, or you'll be alt-tabbing a lot.
-
As mentioned by codingME in another answer, you can use JPDA (http://docs.oracle.com/javase/1.5.0/docs/guide/jpda/conninv.html) command line switches to make your Java VM listen for a debugger connection. Try suspend=y to suspend execution until a debugger connects, avoiding your problem of your program finishing before the debugger connects. By specifying suitable a port number combined with firewall configuration or SSH tunnel setup you can connect to your remote VM over the network. e.g.: -agentlib:jdwp=transport=dt_socket,server=y,address=5005,suspend=y – Neek Jul 24 '12 at 07:14
Assume your program is started by the following command:
java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=<port> <class>
You can attach to this process by jdb:
jdb -attach <port>
In some cases you need to use the following command .
jdb -sourcepath \.src -connect com.sun.jdi.SocketAttach:hostname=localhost,port= <port>
JDB is incredibly difficult to use. Placing System.outs or using an IDE debugger will produce better results. And for the more interesting features (e.g. tracking threads, heap size, etc.), you can get the information graphically with the JConsole tool.
-
2JDB is as easy to use as any debugger, this feedback is unproductive. Also JConsole doesn't allow you to watch variables, set breakpoints, break on exceptions, etc. – Scott S. McCoy Jun 11 '14 at 00:16