JDK-6961123 : setWMClass fails to null-terminate WM_CLASS string
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: solaris_11
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris
  • CPU: generic
  • Submitted: 2010-06-14
  • Updated: 2016-07-21
  • Resolved: 2015-12-29
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 JDK 9 Other
7u111Fixed 8u102Fixed 9 b105Fixed openjdk7uFixed
Description
While debugging a port of the classic xwininfo command from the libX11 to libxcb
API's, I noted that the class info shown for some java windows contained bogus
extra characters on the end.

For instance, while the Xlib version of xwinfo showed:
    0x5400010 "FocusProxy": ("Focus-Proxy-Window" "FocusProxy")  1x1+-1+-1  +1313+1

the xcb version showed:
    0x5400010 "FocusProxy": ("Focus-Proxy-Window" "FocusProxyFra1")  1x1+-1+-1  +1313+1

Digging into this, I discovered that Xlib was hiding a bug in Java.   Xlib always
adds a trailing '\0' byte to property strings, while xcb does not.   This exposes
that Java is not including the trailing '\0' when setting the WM_CLASS string - from
XBaseWindow.java:

    void setWMClass(String[] cl) {
        if (cl.length != 2) {
            throw new IllegalArgumentException("WM_CLASS_NAME consists of exactly two strings");
        }
        XToolkit.awtLock();
        try {
            XAtom xa = XAtom.get(XAtom.XA_WM_CLASS);
            xa.setProperty8(getWindow(), cl[0] + '\0' + cl[1]);
        } finally {
            XToolkit.awtUnlock();
        }
    }

But the ICCCM specifies that unlike most window properties, which are not null
terminated, the WM_CLASS is a special case that must be null terminated:

    Note that WM_CLASS strings are null-terminated and, thus, differ from the 
    general conventions that STRING properties are null-separated.
    This inconsistency is necessary for backwards compatibility.

(BTW, the error message for the IllegalArgumentException seems to have an extra
 "_NAME" on the end of the property name.)

Comments
EVALUATION See the description.
16-06-2010