This section describes issues related to handling key events.
The following keyboard issues are currently unresolved:
On some non-English keyboards certain accented keys are engraved on the keytop and therefore are primary layer characters. Nevertheless, they cannot be used for mnemonics because there is no corresponding Java keycode.
Changing the default locale at runtime does not change the text that is displayed for the menu accelerator keys.
On a standard 109-key Japanese keyboard, the yen key and the backslash key both generate a backslash, because they have the same character code for the WM_CHAR message. AWT should distinguish them. This will be fixed in a future release.
The following keyboard issues concern the Oracle Solaris 10 and Linux x86 systems.
Keyboard input in these systems is usually based on the X keyboard extension (XKB) of the X Window System. Users can configure one keyboard layout (for instance, Danish: dk) or several layouts to switch between (for example, us and dk).
With some keyboard layouts, for instance sk, hu, and cz, pressing the decimal separator on the numeric keypad not only enters a delimiter but also deletes the previous character. This is due to a native bug. A workaround is to use two layouts, for example, us and sk. In this case the numeric keypad works correctly in both layouts.
On UNIX systems that support dynamic keyboard changes, a running Java application does not recognize such a change. For instance, changing the keyboard from US to German does not change the keyboard mapping. Although the X server detects the change and sends out a MappingNotify event to interested clients, AWT does not refresh its notion of the keycode-keysym mapping.
