<AWT Dev> RFC: KeyboardFocusManager patch

[Anton V. Tarasov]

Roman Kennke wrote:
> Hi,
> 
>> My comments concern the DummyKFMPeer (KFM is an acronym
>> for KeyboardFocusManager commonly used in talks here).
>> I thought that it's not good to leave it blank and that we're
>> better to concretize the case when a custom Toolkit doesn't
>> implement KFMPeerProvider interface. Let's consider the following
>> two approaches:
>>
>> 1. We don't create the DummyKFMPeer at all, instead
>> we throw some proper exception if the Toolkit doesn't
>> implement the KFMPeerProvider (i.e. we force it to implement).
>> For instance, we just throw ClassCastException.
>>
>> 2. We create the DummyKFMPeer and make its every method throw
>> OperationNotSupportedException.
>>
>> The both approaches serve to notify the implementator of the Toolkit
>> that it should probably have to provide some logic for the KFMPeer.
>> In case he "forgot" to do it but addressed the peer he would implement,
>> if he didn't need it and he didn't address the peer - nothing happens,
>> when he didn't need it but still addressed he'd make it silent.
> 
> Sounds reasonable to me. I wasn't sure what would be the best way, but
> let the KFM throw NPEs didn't seem wise.
> 
>> The second approach is less strict and is rather more preferable.
> 
> I think both approaches are fine and have more or less the same effect.
> The 1st throws the exception a little earlier. If the reasoning is to
> notify the implementor that there's something missing, this might be
> better because it will pop up even in the smallest HelloWorld example.
> But I guess there will be some initial focus setup on any window, so
> this is not really an argument. Why do you think the 2nd is preferable?
> 

Just because it leaves the implementor a chance not to do additional
work he probably doesn't want to. Say, if he believes he will live without
focus at all (a custom headless toolkit, or kbd-less devises etc.).
Not very useful, of course, but theoretically possible.

Well, actually the question is whose side to take. For us, the 1st approach
is better, for consumers - the 2nd. But taking into account that not many
apps will survive without focus, the both are almost equal.

Thanks,
Anton.