"java.lang.UnsatisfiedLinkError: no awt in java.library.path" in running JWS Swing app

Question

We are sometimes getting this strange error from clients (automatically, no user report was filled until now), and none of us can make sense of it. A user starts our Swing Java-Web-Start "fat client" on a Win7 machine, eventually use some action that should produce a PDF document (using an ancient, modified Apache FOP version), and end up getting this error. So far, it's not reproducible on our side. Google did not help on this one either.

The big question is, how can awt dll be missing, when the awt dll is required to activate the action that causes the error?

Could something be unloading the awt dll? The stack-trace is pretty much always the same, and we found no evidence that this was preceded by some other error. Could this be the result of a non-logged preceding native error?

EDIT: The PDF generation runs in a background thread, while a blocking "wait" dialog prevents the user from closing or otherwise operating the UI.

java.lang.UnsatisfiedLinkError: no awt in java.library.path
    at java.lang.ClassLoader.loadLibrary
    at java.lang.Runtime.loadLibrary0
    at java.lang.System.loadLibrary
    at sun.java2d.cmm.lcms.LCMS$1.run
    at java.security.AccessController.doPrivileged
    at sun.java2d.cmm.lcms.LCMS.getModule
    at sun.java2d.cmm.lcms.LcmsServiceProvider.getModule
    at sun.java2d.cmm.CMMServiceProvider.getColorManagementModule
    at sun.java2d.cmm.CMSManager.getModule
    at java.awt.color.ICC_Profile.getInstance
    at java.awt.color.ICC_Profile.getInstance
    at org.apache.fop.pdf.PDFICCBasedColorSpace.setupsRGBColorProfile
    at org.apache.fop.pdf.PDFICCBasedColorSpace.setupsRGBAsDefaultRGBColorSpace
    at org.apache.fop.render.pdf.PDFRenderingUtil.addsRGBColorSpace
    at org.apache.fop.render.pdf.PDFRenderingUtil.setupPDFDocument
    at org.apache.fop.render.pdf.PDFDocumentHandler.startDocument
    at org.apache.fop.render.intermediate.IFRenderer.startRenderer
    at org.apache.fop.area.RenderPagesModel
    at org.apache.fop.area.AreaTreeHandler.setupModel
    at org.apache.fop.area.AreaTreeHandler
    at org.apache.fop.render.RendererFactory.createFOEventHandler
    at org.apache.fop.fo.FOTreeBuilder
    at org.apache.fop.apps.Fop.createDefaultHandler
    at org.apache.fop.apps.Fop
    at org.apache.fop.apps.FopFactory.newFop
    at org.apache.fop.apps.FopFactory.newFop
    at ...
    at javax.swing.SwingWorker$1.call
    at java.util.concurrent.FutureTask.run
    at javax.swing.SwingWorker.run
    at ...
    at java.util.concurrent.ThreadPoolExecutor.runWorker
    at java.util.concurrent.ThreadPoolExecutor$Worker.run
    at java.lang.Thread.run

EDIT: I found the code that causes the error (in grepcode.com):

/* the class initializer which loads the CMM */
static {
    java.security.AccessController.doPrivileged(
        new java.security.PrivilegedAction() {
            public Object run() {
                /* We need to load awt here because of usage trace and
                 * disposer frameworks
                 */
                System.loadLibrary("awt"); // HERE!
                System.loadLibrary("lcms");
                return null;
            }
        }
    );
// ...
}

Answer 1

This is probably not the cause of the OP's errors, but this is something for others that get here with the same error for another reason.

This error can happen if the version of Java runtime environment updates while the application is still running; e.g. if it is updated through an MSI/EXE installer on Windows, or yum/apt-get/etc. on *nix. After the update, the DLL (Windows) or SO (Linux/Unix) that the running Java application is looking for may no longer be available at the location it knows about, and thus it is not found.

This is more likely in a Unix-like environment, where file locks do not necessarily prevent file deletions, and on a server, where long-running services that only need particular functionality that depends on these DLLs once in a while.

In such cases, a restart of the application is necessary.