"java.lang.InternalError: HTHEME is null" on arbitrary JREs (Windows)

Question

We are getting an exception when changing the Windows Theme on Windows 7 (via right-click Desktop > Personalize) while our Java app is running. Searching the web did produce some results, but they are mostly about java bug reports that claim to have been resolved ages ago. This is the trimmed and partially obfuscated stack trace:

java.lang.InternalError: HTHEME is null
    at sun.awt.windows.ThemeReader.paintBackground(Native Method)
    at sun.awt.windows.ThemeReader.paintBackground(Unknown Source)
    at com.sun.java.swing.plaf.windows.XPStyle$SkinPainter.paintToImage(Unknown Source)
    at sun.swing.CachedPainter.paint0(Unknown Source)
    at sun.swing.CachedPainter.paint(Unknown Source)
    at com.sun.java.swing.plaf.windows.XPStyle$Skin.paintSkinRaw(Unknown Source)
    at com.sun.java.swing.plaf.windows.AnimationController.paintSkin(Unknown Source)
    at com.sun.java.swing.plaf.windows.XPStyle$Skin.paintSkin(Unknown Source)
    at com.sun.java.swing.plaf.windows.XPStyle$Skin.paintSkin(Unknown Source)
    at com.sun.java.swing.plaf.windows.WindowsScrollBarUI.paintThumb(Unknown Source)
    at javax.swing.plaf.basic.BasicScrollBarUI.paint(Unknown Source)
    at javax.swing.plaf.ComponentUI.update(Unknown Source)
    at javax.swing.JComponent.paintComponent(Unknown Source)
    at javax.swing.JComponent.paint(Unknown Source)
    at javax.swing.JComponent.paintChildren(Unknown Source)
    at javax.swing.JComponent.paint(Unknown Source)
    at javax.swing.JComponent.paintChildren(Unknown Source)
    at javax.swing.JComponent.paint(Unknown Source)
    at javax.swing.JComponent.paintChildren(Unknown Source)
    at javax.swing.JComponent.paint(Unknown Source)
    at javax.swing.JComponent.paintChildren(Unknown Source)
    at javax.swing.JComponent.paint(Unknown Source)
    at javax.swing.JComponent.paintChildren(Unknown Source)
    at javax.swing.JComponent.paint(Unknown Source)
    at javax.swing.JComponent.paintChildren(Unknown Source)
    at javax.swing.JComponent.paint(Unknown Source)
    at javax.swing.JComponent.paintChildren(Unknown Source)
    at javax.swing.JComponent.paint(Unknown Source)
    at javax.swing.JLayeredPane.paint(Unknown Source)
    at javax.swing.JComponent.paintChildren(Unknown Source)
    at javax.swing.JComponent.paintToOffscreen(Unknown Source)
    at javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(Unknown Source)
    at javax.swing.RepaintManager$PaintManager.paint(Unknown Source)
    at javax.swing.RepaintManager.paint(Unknown Source)
    at javax.swing.JComponent.paint(Unknown Source)
    at java.awt.GraphicsCallback$PaintCallback.run(Unknown Source)
    at sun.awt.SunGraphicsCallback.runOneComponent(Unknown Source)
    at sun.awt.SunGraphicsCallback.runComponents(Unknown Source)
    at java.awt.Container.paint(Unknown Source)
    at java.awt.Window.paint(Unknown Source)
    at javax.swing.RepaintManager$4.run(Unknown Source)
    at javax.swing.RepaintManager$4.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
    at javax.swing.RepaintManager.paintDirtyRegions(Unknown Source)
    at javax.swing.RepaintManager.paintDirtyRegions(Unknown Source)
    at javax.swing.RepaintManager.prePaintDirtyRegions(Unknown Source)
    at javax.swing.RepaintManager.access$1200(Unknown Source)
    at javax.swing.RepaintManager$ProcessingRunnable.run(Unknown Source)
    at java.awt.event.InvocationEvent.dispatch(Unknown Source)
    at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
    at java.awt.EventQueue.access$500(Unknown Source)
    at java.awt.EventQueue$3.run(Unknown Source)
    at java.awt.EventQueue$3.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
    at java.awt.EventQueue.dispatchEvent(Unknown Source)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
    at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
    at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
    at java.awt.WaitDispatchSupport$2.run(Unknown Source)
    at java.awt.WaitDispatchSupport$4.run(Unknown Source)
    at java.awt.WaitDispatchSupport$4.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.awt.WaitDispatchSupport.enter(Unknown Source)
    at java.awt.Dialog.show(Unknown Source)
    at java.awt.Component.show(Unknown Source)
    at java.awt.Component.setVisible(Unknown Source)
    at java.awt.Window.setVisible(Unknown Source)
    at java.awt.Dialog.setVisible(Unknown Source)
    at com.example.App$130$1.run(Unknown Source)
    at java.awt.event.InvocationEvent.dispatch(Unknown Source)
    at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
    at java.awt.EventQueue.access$500(Unknown Source)
    at java.awt.EventQueue$3.run(Unknown Source)
    at java.awt.EventQueue$3.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
    at java.awt.EventQueue.dispatchEvent(Unknown Source)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
    at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
    at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
    at java.awt.WaitDispatchSupport$2.run(Unknown Source)
    at java.awt.WaitDispatchSupport$4.run(Unknown Source)
    at java.awt.WaitDispatchSupport$4.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.awt.WaitDispatchSupport.enter(Unknown Source)
    ... goes on and on

It seems to be related to LAF. The app does not support changing LAF after startup. It does call

UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());

at startup, however. This happens on a Windows 7 Enterprise x64 machine, running 1.8.0_74 64bit an arbitrary JRE version. This is an example of a Java bug report which appears to be quite similar and is supposedly resolved.

Can anyone shed some light on what the cause may be and how it may be worked around (besides the obvious "do not set system look and feel on Windows")?

P.S.: A comment in the linked bug report claims:

A good application to reproduce the issue is SwingSet3 (https://java.net/projects/Swingset3).

Change Look-and-Feel to Windows, and click JInternalFrame in the list of components on the left. Create several more internal frames. Try switching Windows themes: Windows 7 Basic ??? Windows Classic.

but we had no luck doing that it only happened a single time for us, while SwingSet3 was showing a JTable.

Edit: this indeed happens during Windows Theme changing - either when done manually or when the user logs on to the machine running the Java app through Remote Desktop. To ensure a more responsive interface, Aero may be disabled and a switch to Windows Classic based theme may be made automatically. I've edited the question accordingly.

Ingeminate

Answer 1

The only way around this is to ignore this specific exception instead of throwing it into your user's face, which is exactly what we did. Since it happens during painting, there's no major harm done and the app survives it just fine (during testing at least). This is probably the reason no one cares about actually fixing it (besides Swing dying slowly over time).

If you get HTHEME is null exception and the stack trace mentions a table header renderer, read this answer, if you are using a custom renderer that wraps the default one. That one has a proper solution.

Ingeminate