The last couple of days I went through a little nightmare: I needed to debug a Java application which showed some weird behaviour only when loaded via WebStart, but not when executed within Eclipse.
[Multiple](http://www.jacoozi.com/index.php?option=com_content&task=view&id=119&Itemid=134) [internet](http://javaswamy.blogspot.com/2008/10/debugging-jws-with-eclipse.html) [resources](http://www.ibm.com/developerworks/java/library/os-eclipse-javadebug/index.html) told me to use the `JAVAWS_VM_ARGS` environment variable to tell the Java VM to either create a debug socket itself or connect to some socket started from Eclipse and then simply set a breakpoint there and wait for the meal. But nothing worked out for me, until I found two very important issues nobody wrote about so far:
* Under Java 6 `JAVAWS_VM_ARGS` seems to be completely ignored by `javaws`, on Linux and on Windows. The way to go was to use separate `-J` options in the call to `javaws` – and given a running Eclipse debug server you finally saw the threads of your running application.
* Wait, were these threads really belonging to _your_ running application? This was the second issue. Apparently `javaws` directly forks away as soon as it started and runs your application in a separate VM, which _of course_ did not get the original debug options passed. Again, some internet resources said it would be enough to load the jnlp file from the net and start locally, but actually this did not work out. The magic option to apply to `javaws` here was `-Xnofork` and finally, on the next run I saw my application’s threads in Eclipse and my breakpoints magically worked as expected.
Here is the complete command line example again (given a running Eclipse debug server on port 8000):
javaws -Xnofork -J-Xdebug -J-Xnoagent \
Hope that helps someone 🙂