+1  A: 

No. X11 is the foundation for the window manager and then the Java Swing application that runs in that window environment. So if X11 crashes there's not much you can do.

Mark
+3  A: 

With the right architecture, for many kinds of applications - sure.

Just split the GUI and "core logic" into separate processes, and have the GUI able to detect and reattach to the running backend process when you run it after the crash.

For extra robustness, given that an X crash can often take down the whole system, move to a classic client/server architecture with the backend running over the network.

wrt
A: 

In addition to what wrt said, your backend system could also watch for HeadlessExceptions, and handle them appropriately.

aperkins
Does the JRE actually throw these when the X connection dies after it's been opened? A quick googling leaves me unenlightened.
wrt
Now that you mention it, I am not completely sure - I do know that when we had a misconfigured x11 in a testing environment (or a completely headless machine) it threw them all over the place - which was awful for unit testing. I believe it would, because the machine would now be headless. As long as the back end process was still going, you should be ok.
aperkins
A: 

It is generally not practical for an X11 desktop application to recover from a crashed X11 service, whether it is written in Java or another language.

But it may be possible to prevent the problem happening to a Java app the first place. I recall having to deal with this a long time (5+ years) ago. Sun had a workaround that involved setting a system property to tell the JVM to not use 2D graphics acceleration. I cannot recall the details, but you may be able to find an equivalent solution on the Sun website.

Stephen C