Dan is the founder of Rectangular Software, an independent UK software company that provides development services and builds its own mobile and web applications. Dan has over a decade of experience in the software industry, building a wide variety of systems including casino, poker and spread-betting platforms, mobile applications, e-commerce websites, and network security software. His other programming interests include artificial intelligence, particularly evolutionary computation, and functional programming in Haskell. He has authored, or contributed to, a number of open source Java projects. Dan has posted 34 posts at DZone. You can read more from them at their website. View Full User Profile

Debugging Java Web Start Applications

  • submit to reddit

How do you attach a debugger to a Java Web Start application? Normally you probably wouldn’t bother, just start the application without Web Start and debug as normal. However, if you have a bug that shows up only when running in the Web Start sandbox, as I did today, that won’t help.

The SecurityManager restrictions were causing a different branch of my code to be executed than when launching the application from IDEA or the command line. It was not immediately obvious how to attach the debugger to the Web-Started VM.
In IDEA, to remotely attach a debugger to the JVM, you should start the VM with following set of switches (or similar):

-Xdebug -Xnoagent -Djava.compiler=NONE

Where do these switches go when launching a Web Start application? Normally you launch the application by just clicking a JNLP link in your browser. One option, which doesn’t work, is to specify the JVM arguments in JNLP file. You can already do something like this:

<j2se version="1.5+" java-vm-args="-ea -server"/>

 Adding the debug switches is trivial… and futile. The problem is that remote debugging requires the VM to open up a socket to accept connections from the debugger. Rather sensibly, Web Start does not permit untrusted applications to open sockets on users’ machines. I don’t know if it would work if the application was signed, I was too lazy to go through the hassle of signing the code.

If you want to open a socket on the client machine for debugging purposes, you are going to have to do it from the client machine rather than the JNLP file. The solution is to set the JAVAWS_VM_ARGS environment variable to include the debug switches and then to launch the javaws executable and point it at the unmodified JNLP file. From a bash shell it looks like this:

export JAVAWS_VM_ARGS="-Xdebug -Xnoagent blah blah" javaws http://www.example.com/path_to/application.jnlp

You can then attach the debugger as normal.

From http://blog.uncommons.org/

Published at DZone with permission of its author, Dan Dyer.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Matthew McCullough replied on Mon, 2009/02/09 - 10:47am

Signing JARs can be a tricky thing in JNLP, as certain JARs, such as Java Encryption/JCE providers, have to have a certain company (Sun) Certificate Signature to even function. I've been using and working on the Maven Webstart Plugin to make this easier though in our build environment. It really does make it a breeze.

Mike Miller replied on Tue, 2009/02/10 - 10:46am

Another option similiar to the one shown (pointing to the JNLP URL) is to point to a copy of the downloaded JNLP file that you saved to your file system and pass that filepath to as a command line parm.

 We have several JNLP clients and support both 1.4 and 1.5.  I noticed some strangeness at times when attempting to debug a process using 1.4 and having the JAVAWS_VM_ARGS defined.   I got to the point where I only defined that environment variable when I specifically was attempting to debug one of the JNLP clients.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.