JDK-4068241 : RFE: java.awt.event.KeyEvent doesn't have VK values for Asian/European keyboards
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: java.awt:i18n
  • Affected Version: 1.1.3,1.1.5
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris_2.6
  • CPU: generic,sparc
  • Submitted: 1997-07-30
  • Updated: 1999-01-15
  • Resolved: 1999-01-15
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.
Other
1.2.0 1.2beta4Fixed
Related Reports
Relates :  
JDK-4102301 - RFE: AltGr key needs to be defined in KeyEvent
Relates :  
JDK-4116859 - RFE: Keyboard enhancements to support 3270 keyboards around the world (I18N)
Relates :  
JDK-4099971 - RFE: Need VK constant for Euro sign
Relates :  
JDK-4295215 - wrong keyCode is returned for `@', `:' and `^' on japanese keyboards
Relates :  
JDK-6680988 - KeyEvent is still missing VK values for many keyboards
Description
[naoyuki 7/30/97]
JDK1.1.*'s java.awt.event.KeyEvent does not have
VK_COLON(0xBA) for ':',  VK_AT(0xC0) for '@', and VK_CIRCUMFLEX(0xDE) for '^'.

These keys are inputed with Japanese PC106 keyboard or 
Japanese Sun Keyboard without modifier keys.
So VK_ value for these keys are nessesaly.

JDK1.1.3 implementations are
 Win32:	  store correct values (Windows VK value) 
	  into keyCode variable for these key's KEY_PRESS/KEY_RELEASE event
 Solaris: store 0 (VK_UNDEFINED) into keyCode variable for 
	  these key's KEY_PRESS/KEY_RELEASE event.

So the first bug is java.awt.event.KeyEvent has no constant variable for
':', '@' nor '^'.
The second bug is Solaris/AWT implementation stores VK_UNDEFINED value into
KEY_PRESS/KEY_RELEASE KeyEvent's keyCode for ':', '@' and '&'.

I'm not sure about other countries keyboard, but basically any key has
possibility to be inputed without modifier keys considering l10n keyboard, so
every key code which appear in popular keyboard should be pre-defined 
in KeyEvent class, I believe.

This bug report states only about Japanese keyboard.
------------------------------------------------------------------------
[naoyuki 8/13/97]
Here is the input from Ginger Ward about European keyboard.

----- Begin Included Message -----

Date: Thu, 7 Aug 97 10:31:49 JST
From: ###@###.### (Ginger Ward (Ferguson))
Subject: [LUNA-IM:121] Virtual-Key Keysym definitions missing
To: ###@###.### (luna-im)
Cc: ###@###.###

I've been noticing that as I write more keysym-
to-Virtual-Key tables, for use in my localized
keyboard classes, I find that I need additional
Virtual Key keysyms that aren't in the 
java.awt.event.KeyEvent class.  This is annoying
in the sense that it seems that for each keyboard
I write, I find more VK keysyms that aren't present.

I'm concerned, as I would like to be able to add
new keyboard classes rather seemlessly, I mean without
having to add stuff to the base JDK to support them.

Here I list the additional Virtual Key keysyms needed for 
the scancode-VK keysym (few) tables I've done so far. 
These are needed to support the following keyboards:

  danish, french, italian, spanish, uk
  german, swedish

KeyEvent.VK_ampersand
KeyEvent.VK_apostrophe
KeyEvent.VK_asciicircum
KeyEvent.VK_asterisk
KeyEvent.VK_backslash
KeyEvent.VK_colon
KeyEvent.VK_diaeresis
KeyEvent.VK_dollar
KeyEvent.VK_exclam
KeyEvent.VK_exclamdown
KeyEvent.VK_greater
KeyEvent.VK_less
KeyEvent.VK_numbersign
KeyEvent.VK_parenleft
KeyEvent.VK_parenright
KeyEvent.VK_plus
KeyEvent.VK_quotedbl
KeyEvent.VK_semicolon
KeyEvent.VK_underscore

(I used the Xlib keysym names as advised by Tom Ball.)

Perhaps there's a better way for me to do this.  It seems 
that as I add keyboards I'll keep asking you all to add 
VK keysyms.  There must be a better way.  If anyone has 
any good ideas, please email.

However, for now, can these please be added to the
java.awt.event.KeyEvent class?

=Ginger

----- End Included Message -----

[norbert@eng 1998-02-23]

IBM and other licensees have also requested additional VK constants to fully support localized keyboards, for example:
      hiragana 
      katakana 
      alpha-numeric 
      Roman input 
      all candidates 
      previous candidate 
      Kanji code input 
      half size 
      full size 

norbert.lindenberg@Eng 1998-02-23
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.2beta4 FIXED IN: 1.2beta4 INTEGRATED IN: 1.2beta4
14-06-2004
SUGGESTED FIX Java API Addition Request: Adding Virtual Key Constants to KeyEvent Problem Several licensees, including IBM, Justsystem, and SunSoft, have requested additional virtual key constants in KeyEvent to support keys that exist on non-US keyboards. IBM and Justsystem are primarily interested in function keys that are used by input methods: hiragana katakana alpha-numeric Roman input all candidates previous candidate Kanji code input half size full size By current rules for VK constants, some of these don't qualify for their own VK constants. The rule so far has been that VK constants are only defined for separate keys, not for the different characters/functions that can be generated from one key by modifier keys. Exceptions were made if an important underlying operating system generates separate VK values from the same key. From the list above, the functions "all candidates", "previous candidate", and "code input" would not qualify under these rules, since they are produced using the Shift or Alt modifiers with other keys, and we don't know of any operating system that generates specific VK values for them. However, it is necessary for input methods to be able to recognize these functions in a platform-independent way, without interpreting Alt/Shift modifier combinations. We considered a number of alternative ways to provide platform-independent information, but they all involved substantial new API. So we decided (with approval from Tom Ball) to modify our rules and to provide separate VK constants even for these three functions. Apple Technology requested constants for two additional keys that are found on Japanese Macintosh keyboards: kana (switches to Japanese input method in hiragana or katakana mode, depending on Shift key) eisu (switches to Japanese input method in roman-direct mode) SunSoft requested virtual key constants for character keys that are used on the primary layer on non-US keyboards, such as colon, at, opening or closing parenthesis. SunSoft also noticed that there's no constant for the AltGraph modifier key. Since this is a modifier key, a mask value is required as well. Similarly, a constant for the Compose function key needs to be added. Alcatel requested support for the Euro currency symbol. It is not clear yet whether a VK constant is actually needed, since the European Commission has two proposals for keyboard support for the Euro: It might be generated by typing AltGraph-E, or a new physical key might be added. The second solution requires a new VK constant. It appears that at least Alcatel is planning to adopt this solution. SMCC is requesting VK constants for additional keys on the IBM 122 keyboard, which is used for 3278 terminals. RFE 4068241 - java.awt.event.KeyEvent doesn't have VK values for Asian/European keyboards 4099971 - Need VK constant for Euro sign 4102301 - AltGr key needs to be defined in KeyEvent 4116859 - Keyboard enhancements to support 3270 keyboards around the world Requestors Norbert Lindenberg for IBM Japan, Justsystem, Apple Technology, SunSoft, Alcatel, SMCC Proposed API change In java.awt.event.InputEvent, add: /** The alt-graph key modifier constant. */ public static final int ALT_GRAPH_MASK /** Returns whether or not the Alt-Graph modifier is down on this event. */ public boolean isAltGraphDown() In java.awt.event.KeyEvent, add: /** Constant for the Alphanumeric function key. */ public static final int VK_ALPHANUMERIC /** Constant for the Hiragana function key. */ public static final int VK_HIRAGANA /** Constant for the Katakana function key. */ public static final int VK_KATAKANA /** Constant for the Roman Characters function key. */ public static final int VK_ROMAN_CHARACTERS /** Constant for the All Candidates function key. */ public static final int VK_ALL_CANDIDATES /** Constant for the Previous Candidate function key. */ public static final int VK_PREVIOUS_CANDIDATE /** Constant for the Code Input function key. */ public static final int VK_CODE_INPUT /** Constant for the Full-Width Characters function key. */ public static final int VK_FULL_WIDTH /** Constant for the Half-Width Characters function key. */ public static final int VK_HALF_WIDTH /** Constant for the Japanese-Hiragana function key. * This key switches to a Japanese input method and selects its Hiragana mode. */ public static final int VK_JAPANESE_HIRAGANA /** Constant for the Japanese-Roman function key. * This key switches to a Japanese input method and selects its Roman-Direct mode. */ public static final int VK_JAPANESE_ROMAN /** Constant for the "@" key. */ public static final int VK_AT /** Constant for the ":" key. */ public static final int VK_COLON /** Constant for the "^" key. */ public static final int VK_CIRCUMFLEX /** Constant for the "$" key. */ public static final int VK_DOLLAR /** Constant for the Euro currency sign key. */ public static final int VK_EURO_SIGN /** Constant for the "!" key. */ public static final int VK_EXCLAMATION_MARK /** Constant for the inverted exclamation mark key. */ public static final int VK_INVERTED_EXCLAMATION_MARK /** Constant for the "(" key. */ public static final int VK_LEFT_PARENTHESIS /** Constant for the "#" key. */ public static final int VK_NUMBER_SIGN /** Constant for the "+" key. */ public static final int VK_PLUS /** Constant for the ")" key. */ public static final int VK_RIGHT_PARENTHESIS /** Constant for the "_" key. */ public static final int VK_UNDERSCORE /** Constant for the F13 function key. */ public static final int VK_F13 /** Constant for the F14 function key. */ public static final int VK_F14 /** Constant for the F15 function key. */ public static final int VK_F15 /** Constant for the F16 function key. */ public static final int VK_F16 /** Constant for the F17 function key. */ public static final int VK_F17 /** Constant for the F18 function key. */ public static final int VK_F18 /** Constant for the F19 function key. */ public static final int VK_F19 /** Constant for the F20 function key. */ public static final int VK_F20 /** Constant for the F21 function key. */ public static final int VK_F21 /** Constant for the F22 function key. */ public static final int VK_F22 /** Constant for the F23 function key. */ public static final int VK_F23 /** Constant for the F24 function key. */ public static final int VK_F24 /** Constant for the Compose function key. */ public static final int VK_COMPOSE /** Constant for the AltGraph function key. */ public static final int VK_ALT_GRAPH We don't have complete information about Korean and Chinese keyboards yet, so this list may still see two to three additions. Implementation: Following existing usage, we will use the Windows VK values for the VK constants where possible, so that little mapping code is necessary on Windows (it will be necessary for the "all candidates", "previous candidate", "code input" functions). For Solaris, the existing mapping table will be extended to handle new key constants. The code and tables that produce human-readable names for the keys also need to be updated. The implementation will be done by Norbert. Reviewed by Masayoshi Okutsu Risk assessment: Adding these constants poses no risk. Actually using them in the generation of KeyEvents means modifying AWT code that is hardly ever tested, but typically the changes should only involve modifying tables. This API change doesn't fully address the needs of input methods. Some functions are stateful, and an interface is needed to determine and set the state (4125419). SQE (product testing) impact: Manual testing with a number of non-US systems is necessary to verify that the new values are generated correctly. Cindy Jao: This requires extra resources (such as manpower and equipment) from this group. JCK (compatibility testing) impact: Approved by Steve Fleming: JCK will test that the constants have the same value on the implementation being tested. Doc impact: Javadoc documentation is provided as shown above. No additional documentation is necessary. Approved by Dale Green. Localization impact: The table of key names in the awt.properties file will be extended. The new names will have to be translated. Internationalization impact: This change is necessary to support non-English keyboards and input methods. Security impact: None. Legal impact: None.
11-06-2004
EVALUATION Implemented suggested fix. norbert.lindenberg@Eng 1998-05-07
07-05-1998