"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;
            }
        }
    );
// ...
}

Mazuma

I think there is some other missing dll/lib. Can you ask your client to reinstall the jdk ? – Toga

I finally got a reply from our hotline. No client reported this error, which basically mean they either did no see it, or worked around it with a simple restart of the application (our clients would not be able/allowed to reinstall Java themselves...). – Mazuma

We got the same thing with an automated bug report from one of our users, but not a clue: josm.openstreetmap.de/ticket/13973 Did you submit a bugreport to Oracle at the time? – Lazulite

@Lazulite From experience, error reports that are not "reproducible" and without a "test-case" get little to no attention (everywhere, not just at Oracle), so I must admit I did not bother sending a report to Oracle. – Mazuma

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.

Selective

As you say, it's probably not the answer to my specific problem, but it is still a really good point. +1 – Mazuma