If you enable the XKB extension on the Linux or Solaris X servers the
Toolkit.getLockingKeyState() method never returns the correct values.

In the case of XKB off, the call used to determine the state of the
locking keys is valid, in that it will set the correct bit in the mask
for the lock keys if the toggle is on. Unfortunately in the case of
XKB being enabled this is no longer the case, in and this state bit
is only set if the key is physically held down. This is best described
in a quote from a discussion I had with Ivan Pascal in the XFree86
organisation:

     It's a compatibility issue. True. But is it a bug of a new extension? I
     don't think so. The problem is an unflexibility and even a dumbness of a
     core protocol in the keyboard part. It assumes modifier bits are
     strongly bound to keys (not kesyms) and they automaticaly change a state
     with a changing of key logical state.

     But in XKB all modifiers can be changed by actions that are bound to
     keysyms. And there are at least two methods to change a modifier bit: a
     temporary activation while a key is physycaly down and a 'toggling' where
     a modifier keeps its state after a key release until a next pressing.

     It allows to control modifiers in a more flexible way. The same key can
     change more the one modifier (and do some other tasks) in depend on other
     modifier keys (such as Shift/Alt/Ctrl) state or a current layout (XKB
     allows to have up to four layouts in a one keyboard map).

     For example, the NumLock key your are talking about, in default
     configuration do two tasks. Being pressed alone it changes the NumLock
     modifier bit but with Shift key pressed it toggles the 'Mouse Keys mode'.
     And how you suggest to interpret its 'logical state'? As the modifier
     state or the state of Mouse Keys mode?

On Linux XKB is enabled by default, on Solaris it's not, but should be
for accessibility support.

This is a core API of Java and should be fixed to return the correct values
regardless of the Xserver configuration.

Because of this it's not possible to correctly implement the Java Accessiblity
Bridge for GNOME such that it can inform GNOME Accessibility Tools about
the state of keys such as NUM_LOCK / CAPS_LOCK, etc.

I've attached a simple program led.c that implements the same mechanism
used by Java to determine the key states - try running it with XKB
off first, and you can see the expected behaviour. Then turn on XKB
and see how the behaviour differs.

BTW, this is not specific to any single version of Java, it seems to be
present in ALL implementations of Sun VMs that I've tested from 1.4 up...