<Swing Dev> Unexpected NullPointerException by endComposition()

[Pavel Porvatov]

Hi Charles,
> On 10/14/2011 04:06 PM, Pavel Porvatov wrote:
>> Hi Charles,
>>> On 10/11/2011 05:50 PM, Pavel Porvatov wrote:
>>>> Hi Charles,
>>>>> On 10/08/2011 05:41 PM, Pavel Porvatov wrote:
>>>>> I got your point. What about this solution:
>>>>> If in the compose mode, endCompositoin just sendComposedText 
>>>>> instead of sendCommittedText.
>>>>>
>>>>> The patch is attached
>>>>>
>>>> Could you please explain the fix? May be it removes NPE but it 
>>>> puzzles me. So if buffer.length() == 0 you invoke 
>>>> sendCommittedText, right? But sendCommittedText commits buffer, but 
>>>> buffer is empty. Looks strange...
>>>>
>>>> BTW: the code like "if (!notInCompositionMode) {" a little bit 
>>>> difficult to understand =) I'd preffer to avoid two negations and 
>>>> use "if (notInCompositionMode)" and swap if/else blocks...
>>>>
>>>> Regards, Pavel
>>>>
>>> Hi Pavel,
>>>
>>> Sorry for the confusion. Here is some explanation, please correct me 
>>> if I am wrong:
>>> 1. There two modes which is judge from the buffer size: composed 
>>> mode when the buffer size is not zero and normal mode when the 
>>> buffer size is zero.
>> Right
>>> 2. The original code make no difference whether it is in the 
>>> composed mode or normal mode. In the normal mode, which buffer size 
>>> is zero, it sends the committed text. In the composed mode, which 
>>> buffer size is not zero, it also sends the committed code. And NPE 
>>> occurred here.
>>> 3. In the patch, I do not change the logic when in the normal mode. 
>>> (notInCompositionMode branch)  Why? I guess it is the logic of "Ends 
>>> any input composition that may currently be going on in this 
>>> context. Depending on the platform and possibly user preferences, 
>>> this may commit or delete uncommitted text." from the api spec....
>> Yes. But after your change the following code looks strange for  me:
>>         if (!notInCompositionMode) {
>>            ....
>>         } else {
>> >>>>            sendCommittedText();
>>         }
>> So if we are not in composition mode we send something (empty string 
>> actually). Logically we shouldn't send anything (IMO), because buffer 
>> is empty. Why should we do something at all if endComposition is 
>> invoked and we are not in composition mode?
>>> 4. In the patch, the logic in the composed mode is that: if it is in 
>>> the composed mode, keep every thing as just composed :-)
>>
>> I found a new bug (???) in the fix. If you apply the patch, run the 
>> MouseEventTest2 test and follow the instructions from the bug 
>> description NPE will not be thrown, but the JTextArea remains in 
>> composition mode even after endComposition completion.
>
> Right. It seems that we have to do some thing in the jdk :-). Here it is:
>
> The patch attached is just adding a null check at the beginning of the 
> mouseClicked method in DefaultCaret. So why the component is null in 
> the DefaultCaret? That because the caret has already been deinstalled. 
> It seems to be an order problem of mouse event and the event which 
> endCompositon sent. The endComposition will exchange the caret and 
> deinstall the old one. On the other hand, mouse click event was 
> happening on the old caret. So the component of the old caret is null 
> now. NPE happens.
It looks that you are trying to fix the consequence, but not the root of 
the problem. The endComposition method shouldn't send anything to 
deinstalled DefaultCaret. I think the previous version of the fix was 
much closer than this one.

Regards, Pavel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20111027/04e5fb58/attachment.html>