Skip to content

debugging

Especially when you are using fat jar files to make them behave like an executable you get into trouble when you want to debug them.

tldr

This script did the trick in the idcheck tool :

idcheck example
1
2
export CLASSPATH=/home/kees/projects/tools/id3/build/libs/id3-all-1.0.jar
jdb -sourcepath src/main/java org.klopt.tools.App ~/Desktop/tagged

If you run it you will get the next line, and you need to attach to that port using jdb :

run
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
idcheck.sh .
Listening for transport dt_socket at address: 5005
jdb --attach 5005

Initializing jdb ...

VM Started: > No frames on the current call stack

main[1] stop in org.klopt.tools.App.main
run

For this particular tool id3, I already made a jdb.sh script to show how it should be started without remote debugging. It is in the tools/id3 directory.

jdb.sh
1
2
export CLASSPATH=/home/kees/projects/tools/id3/build/libs/id3-all-1.0.jar
jdb -sourcepath src/main/java org.klopt.tools.App ~/Desktop/tagged

Here the breakpoint works if you supply the complete class name :

stop
1
stop in org.klopt.tools.App.main

explanation

  • The main problem is that jdb cannot find the correct starting class so setting the classpath to the exact location of the jar handles that.
  • You need to specify the class to start explicitly so that is the 'org.klopt.tools.App' part on the commandline of jdb.
  • But then it still cannot find the sources so use -sourcepath for that.
  • As you can see you need to start this file in the top directory of ~/project/tools/id3 because it uses a relative path to the source.
  • This means you need to give the correct path as an argument to the App, which is the last parameter to jdb.