JDK-6942481 : Invalid value of VK_PLUS and many others, see bug 4262044
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6u16
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2010-04-09
  • Updated: 2011-02-16
  • Resolved: 2010-05-19
Related Reports
Relates :  
Description
FULL PRODUCT VERSION :
Picked up _JAVA_OPTIONS: "-Dsun.java2d.opengl=true -Dsun.java2d.d3d=true"
java version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) Client VM (build 14.2-b01, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
 Windows XP [Version 5.1.2600]

EXTRA RELEVANT SYSTEM CONFIGURATION :
javac 1.6.0_16

A DESCRIPTION OF THE PROBLEM :
This is to reopen the never fixed, and yet closed bug 4262044.

I have just spend a days work on discovering why KeyEvent.getKeyCode() never returns KeyEvent.VK_PLUS or KeyEvent.VK_MINUS and several others, to finally after a series of fruitless experiments to "Google web" for the issue, and to discover bug 4262044 filed 1999, closed without a fix in all these years!

This is very unsettling. Please be so nice to accept that I am unable to understand what is the problem, to understand the quite convoluted wording of the evaluation of the bug 4262044.

Which key has than the key code == VK_PLUS, if not the "+/=" or the keypad "+"?

What value have the VK-codes than , if they are wrong, at least some of them are wrong?

What is than the VK_nnn code for "=/+" of they keypad "+"?


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Use the code from bug 4262044, still the same problem shows up.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
At least the keypad "+" key pressed should cause KeyEvent with KeyCode=VK__PLUS.
ACTUAL -
Node of the keys delivers VK_PLUS, VK_MINUS, VK_EQUALS, to name a few. I do not even known how many of the VK_nnn codes are wrong alongside of these codes.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.awt.event.*;
import javax.swing.JFrame; ,
import javax.swing.JTextField;
/* vernatim copy from bug 4262044 */
public class KeyBug extends JFrame
{
	JTextField feld;
	
	public KeyBug()
	{
		feld = new JTextField();
		feld.addKeyListener(new KeyAdapter()
		{
			public void keyPressed(KeyEvent evt)
			{
				System.out.println("KeyCode=" + evt.getKeyCode());
				System.out.println("KeyChar=" + evt.getKeyChar());
			}
		});
		this.getContentPane().add(java.awt.BorderLayout.NORTH, feld);
		this.pack();
		this.show();
	}
	
	public static void main(String[] args)
	{
		System.out.println("PLUS - KeyCode: " + KeyEvent.VK_PLUS);
		KeyBug keyBug = new KeyBug();
	}
}

---------- END SOURCE ----------

Comments
EVALUATION Spec says, "Not all keyboards or systems are capable of generating all virtual key codes. No attempt is made in Java to generate these keys artificially." (see java.awt.event.KeyEvent). In case of VK_PLUS, one easily can get it -- but in German keyboard layout or similar, with non-keypad "+" on the primary layer. Re: primary layer concept, see the spec again. In English layout, + is not on the primary layer, thus no VK_PLUS available. Note again in spec something even more strong: "Not all characters have a keycode associated with them. For example, there is no keycode for the question mark because there is no keyboard for which it appears on the primary layer." (As a side note, presently there is such a layout but I cannot find a single person using it). Finally, a keypad + yields VK_ADD, and we cannot and should not change it.
19-05-2010