The KeyEvent class gives 3 indications of keyboard activity -
   keyPressed(), keyTyped(), keyReleased()

For the keypad the value of the keycode field on keyPressed()
and keyReleased() is dependant on whether numlock is on or off.

e.g.
   the keypad del key
      Numlock on KEY_PRESSED gives a keycode of 110 which is
         different from the . key on the main keyboard
      Numlock off KEY_PRESSED gives a keycode of 127 which is
         the same as the DEL key on the main keyboard

This means it is not possible to consistantly tell whether
the key press being processed comes from the keypad or the 
main keyboard. As a result the additional VK_* codes provided
in JDK 1.1 are largely of no practical use what ever.



======================================================================

N/A

This bug seems related to 4057663 if not exactly the same. Bug 4057663 has been fixed.

  xxxxx@xxxxx   1997-12-07

The original user who submitted this bug believes this bug is similiar to 
4057663 but not the same.   The user states that what this bug boils
down to is the fact that it is is not always possible to tell which 
physical key was pressed to generate a logical keyTyped.

On the user's keypad one of the keys is ". or Del" depending on the 
numlock key. If numlock is on, everything is fine you can tell the difference 
between . on the keypad and . on the keyboard

If numlock is off it is not possible to tell whether Del was pressed 
on the keypad or the keyboard
As some applications require the ability to remap the keyboard this 
is a real problem.

The user has stated that you can call him if you need additional
clarification.  His phone number is in the comments section.

  xxxxx@xxxxx   1998-01-22

This is an expansion of this behaviour, dealing
only with keyPressed events
[I am not the original poster, btw]
Funnily enough, the behaviour for keypad stuff
is different for the java that comes bundled with
solaris 2.6
jdk1.1.4:
the "Up" arrow on the numberpad returns the
"Up" keycode, the exact same as the "normal"
up-arrow key.
solaris 2.6 java:
IFF numlock is ON, the arrow keys return
"Numpad 0" through "Numpad 9".
However, "Delete" on the pad does not change.
And the /,*,- keys have a behaviour which I won't
even describe here, it's too embarassing.
If Numlock is OFF, then (for example) numpad 7
acts as "Home", and returns the same keycode
as the regular "Home" key.
I think this behaviour is resonably consistant
with what people might expect.
I would cast my vote to have future jdk's follow
the solaris 2.6 behaviour, but additionally FIX
the numpad 'delete', and other keys, to be
differentiable, if numlock is on.

I just did a search for bug ID "4057663".
The search turned up nothing.

A response to the comments by theferret 
(and I am the original bug reporter btw)
With respect
No, no, no, NO.
Whilst I have no objections to say the keyPressed
event returning a key value dependant on the
state of the Num Lock key it MUST be possible
to know which key generated the original key
press otherwise any type of key mapping on
the keyboard will be impossible.
Any application which wishes to do certain
actions when a key is pressed (e.g. a Terminal
emulator - on a VT100 the keypad are function
keys - and there are many other examples) will
have its behaviour altered just because the
Num Lock key has been pressed.
It took windows several releases to sort this
problem out. I hope Java will manage it faster.
Also 4057663 still doesn't exist and as this
problem exists in 1.2 I don't think it is the
same

Poster "pericom" is exactly correct.  This makes
implementing a reliable VTXXX emulator (and probably
others) very difficult if not impossible.

I am having the same problem distinguishing the Enter key on the keypad from
the main Enter key.   Both report the same key code (10) and modifiers (none). 
 Any solution yet.