<Swing Dev> Unexpected NullPointerException by endComposition()

Charles Lee littlee at linux.vnet.ibm.com
Wed Oct 12 04:44:04 UTC 2011


On 10/11/2011 05:50 PM, Pavel Porvatov wrote:
> Hi Charles,
>> On 10/08/2011 05:41 PM, Pavel Porvatov wrote:
>>> Hi Charles,
>>>> On 10/07/2011 05:11 PM, Pavel Porvatov wrote:
>>>>> Hi Charles,
>>>>>> On 10/03/2011 05:40 PM, Pavel Porvatov wrote:
>>>>>>> Hi Charles,
>>>>>>>> On 09/22/2011 05:18 PM, Neil Richards wrote:
>>>>>>>>> On Thu, 2011-09-22 at 14:21 +0800, Charles Lee wrote:
>>>>>>>>>> Hi guys,
>>>>>>>>>>
>>>>>>>>>> The webrev is attached.
>>>>>>>>> For ease of review, I've uploaded the webrev to 
>>>>>>>>> cr.openjdk.java.net [1]
>>>>>>>>>
>>>>>>>>> Regards, Neil
>>>>>>>>>
>>>>>>>>> [1] http://cr.openjdk.java.net/~ngmr/6938583/webrev.00
>>>>>>>>>
>>>>>>>> Hi guys,
>>>>>>>>
>>>>>>>> Any update about this issue? Is the idea workable?
>>>>>>>>
>>>>>>> Can you explain why should we consume right clicks but not left 
>>>>>>> ones? (May be there are other test cases when NPE is thrown... ) 
>>>>>>> And why do you consume event? (May be it hides NPE but breaks 
>>>>>>> functionality)
>>>>>>>
>>>>>>> Thanks, Pavel
>>>>>>>
>>>>>>
>>>>>> 1. When right clicks, it suppose to show a manu on where you 
>>>>>> click. But I guess the demo (CodePointIM) is not suppose to show 
>>>>>> that (what will be show when use CodePointIM and right click? 
>>>>>> IIRC, I tried the normal input and right click but get nothing)
>>>>>> 2. If point 1 is true, consuming the right click in the 
>>>>>> CodePointIM is the easiest way to fix it and less error-prone 
>>>>>> comparing with fixing in the jdk...
>>>>>> 3. Consuming left click will disable the movement of the input 
>>>>>> place by clicking, I guess...
>>>>>>
>>>>> There is no information about popup menu in the bug description. 
>>>>> The problem is that endComposition() throws NPE if Input Method is 
>>>>> turned on and the program is in composition mode. If you apply 
>>>>> your fix and change BUTTON3 into BUTTON2 in the MouseEventTest2 
>>>>> test (see bug description), then NPE will be thrown with your 
>>>>> patch as well...
>>>>>
>>>>> Regards, Pavel
>>>>
>>>> Why change Button3 to Button2? Does Button3 reflect the right click?
>>> No, Button2 is the middle button. But if you use Button2 in the 
>>> MouseEventTest2 the test is still valid and it shouldn't throw any 
>>> unexpected exceptions. But if you apply your fix and replace Button3 
>>> by Button2 in the MouseEventTest2 test, run the MouseEventTest2 test 
>>> and use testcase from the bug description (of course in step 5 you 
>>> should use the middle mouse button now) you'll get NPE
>>>>
>>>> NPE was occurred because the component is null. Component becomes 
>>>> null because the default carret, IIRC, has been changed when it 
>>>> receive the right click event. It is the right behavior, if I 
>>>> understand correctly. So I am trying to disable the right click 
>>>> event if the demo does not suppose some menu should going to show up.
>>>>
>>> I still don't understand where do you see popup menu? I wrote about 
>>> the test from 
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6938583 and there 
>>> is no popup there...
>>>
>>> Regards, Pavel
>> 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.
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....
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 :-)

-- 
Yours Charles

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20111012/cc8fc3a7/attachment.html>


More information about the swing-dev mailing list