We had a meeting on this a while back, but I'm going to file a bug on it as we are running into this problem more and more.
The basic problem is that when Swing gets a KeyTyped event we have no way of  customer  if it is a valid key combination, or perhaps the only way to type the key. For example, pressing Ctrl-c results in a KeyTyped with a 'c' char and CTRL modifier. Typically you don't want such key sequences to appear in a text widgets, and thus we filter them. We also filter Alt keys for the same reason. The problem then comes that in some locales and some keyboards you need to type alt to produce certain characters. Since we filter these out, the user can then no longer enter these characters.

. Don't produce KeyTyped events unless this is the only way to enter the character.
. Provide some API to determine if this is the only way to enter the character.

N/A

We should try to look at this in the Merlin time frame.  
However, changing the way we report modifiers will 
be hard; there are a number of regression tests that 
codify the way we do it now, and we have at least one 
licensee who feels strongly that we should do it this way.  

Commit to fix in merlin (swing).  
  xxxxx@xxxxx   2001-04-06

For some perspective: 

On Mac OS, with common non-US keyboard layouts, eg, German, 
you need to use the 'alt' key to type some very very common 
characters. eg, '['

As you can imagine, this makes it very hard to use Netbeans/
Forte in the Metal Look and Feel, if you are a European Mac 
user.

The decision to ignore all alt+keystroke events in Metal was 
a very poor one. 

Any progress in the 1.4beta?

'#' is "alt 3" on my uk keyboard... in some java apps I 
have to type a '#' in a native app and then copy and 
paste it into the java app - I can't type one in java.

It depends on why you're writing a KeyListener. 
KeyListeners are appropriate when your interested in 
the actual keystrokes, but they're troublsome when 
your interested in the text being typed. If it's the actual 
text you want to filter, there's a much better way to do it.

When I need to filter text going into a JTextComponent 
(which I often do), instead of writing a KeyListener, I 
override the insertString( ) method of the 
PlainDocument class, and put my filtering code there. 
There are two advantages to doing it this way:

1) Only the events that I'm interested in will pass 
through this method. Any control characters and others 
that I want filtered out will already be removed by the 
standard (and debugged) code before this method is 
called. Also, all characters formed by another locale's 
IME will also be properly formed, and I don't need to 
worry about them.

2) All events that I'm interested in will pass through this 
method. KeyListeners will miss the text that gets 
pasted in through the mouse, and often miss that 
pasted in through control-v, unless the code is written 
to account for this.

When written this way, all the standard ways of 
entering characters from the keyboard get entered as 
they should. It's a trouble-free filtering technique.

Even a facility to tell what keystroke generated the
KEY_TYPED character would be helpful.

If I want java.awt.Robot to generate an arbitrary character,
there is no way to generically map that character to a
keystroke (or vice versa)

For those who took my earlier suggestion to override insertString() instead of using KeyListeners, Sun has since added DocumentFilters to the document class. This is a simpler and more flexible way to do the same thing.