JDK-6244370 : Spec for Component.processFocusEvent/processKeyEvent doesn't match the implementation
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 5.0
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2005-03-22
  • Updated: 2011-04-28
Related Reports
Relates :  
Relates :  
Description
The current specs for Component.processFocusEvent/processKeyEvent
state:

    If focus events are enabled for a Component, the current
    KeyboardFocusManager determines whether or not a focus
    event should be dispatched to registered FocusListener
    objects. If the events are to be dispatched, the
    KeyboardFocusManager  calls the Component's dispatchEvent
    method, which results in a call to the Component's
    processFocusEvent method.

    If focus events are enabled for a Component, calling the
    Component's dispatchEvent method with a FocusEvent as the
    argument will result in a call to the Component's
    processFocusEvent method regardless of the current
    KeyboardFocusManager.

    ....

    If key events are enabled for a Component, the current
    KeyboardFocusManager determines whether or not a key event
    should be dispatched to registered KeyListener objects.
    <...>

    As of J2SE 1.4, KeyEvents are redirected to the focus owner.
    Please see the Focus Specification for further information.

    Calling a Component's dispatchEvent method with a KeyEvent
    as the argument will result in a call to the Component's
    processKeyEvent method regardless of the current
    KeyboardFocusManager as long as the component is showing,
    focused, and enabled, and key events are enabled on it.

There's a few issues with this doc:

1) Both statements with "..regardless of the current KeyboardFocusManager"
do not match Sun's implementation - the current KeyboardFocusManager is 
consulted even if the event doesn't come from the EventQueue but is synthesized 
by the application and dispatched to the component directly. I attached code 
examples for both cases: just uncomment the redispatchEvent() calls and the 
events will be delivered.

2) The spec for processFocusEvent seems to imply that FocusEvents
are processed *as if* the current KFM is consulted before calling
Component.dispatchEvent(): an implementation may choose to put KFM
calls into Component.dispatchEvent() (it's final anyway, and this 
is how Sun's impl does it), but this should be invisible to
applications. The spec for processKeyEvent happens to be more ambigious 
and does not specify at what point applications will perceive interactions 
with the current KFM.

3) The last statement seems to have contradiction in itself ("regardless of
the current KeyboardFocusManager as long as the component is <..> focused")
since the focused component is actually determined by the current 
KeyboardFocusManager.


###@###.### 2005-03-22 18:45:50 GMT

Comments
EVALUATION Should be resolved in the next release. ###@###.### 2005-06-23 14:19:29 GMT ###@###.### 2005-06-23 16:00:35 GMT
23-06-2005

SUGGESTED FIX I see a couple of options here: A) Rewrite the spec to explain the existing interaction between Component.dispatchEvent() and the current KFM. This would mean that no clean-room spec implementors (including those in J2ME) would ever be allowed to untangle KFM from Component.dispatchEvent() and put it to its proper place in the chain between EventQueue and Component dispatching. B) Modify the implementation to behave as if the current KFM is not consulted for focus and key events not originated from the EventQueue. This will still require slight touch-up of the processKeyEvent spec to make it consistent with processFocusEvent (issue (2) in my description) and to correct the "regardless" statement (issue (3) there). B seems a better call from the API design perspective. I think we should choose it if the backward compatibility issues are not too serious. I hope they aren't, since behavioral changes can potentially be observed only by the apps that synthesize their own AWT events. ###@###.### 2005-03-22 18:45:51 GMT
22-03-2005