JDK-8213183 : InputMethod cannot be used after its restarting
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt:i18n
  • Affected Version: 7,8,11,12
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: generic
  • Submitted: 2018-10-31
  • Updated: 2019-09-09
  • Resolved: 2019-01-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 12 JDK 13 JDK 7 JDK 8 Other
11.0.3Fixed 12Fixed 13 teamFixed 7u231Fixed 8u221Fixed openjdk8u222Fixed
Related Reports
Relates :  
Java application cannot use InputMethod (IM) if IM was restarted.
Some native applications on X-Window can do that.

We need to consider two conditions:
1. IM restarted during Java application is working.
2. Java application started with IM down. Then, IM started.

My first proposal was posted in
I���d like to post the revised one.

<Recreate steps>
1. Launch an application with Text or JText component under East-Asian (Chinese, Korean, or Japanese) environment.
2. Turn on Input Method (IM) on X-Window and input some Asian characters to Text component.
3. kill the IM frontend by OS and restart it. This emulates IM crash or IM restarting to change the configuration. 
   IM frontend depends on environment. For example, ibus-x11, fcitx, kinput2 etc.
   For ibus, 
   $ ibus-daemon -r --xim
   command restart ibus.
4. Change focus to other window and back.
5. Try to repeat the step 2.

We cannot turn on IM. We can input only English characters, but cannot input Asian characters.

<expected result>
We can turn on IM and can use it as same as step2.
Fix Request This fix prevents JVM crash. The effective environment is limited and risk is low. The patch could apply cleanly.

We need to fix two problems about IM restarting. 1) X11 Event mask PropertyChangeMask is required by XRegisterIMInstantiateCallback. But, XMSeletion:initScreen() will overwrite only StructureNotifyMask. 2) JVM crash if both two Windows have input fields. Below are records of X11InputMethodData and X11im. Java_sun_awt_X11_XInputMethod_setXICFocusNative getX11InputMethodData 0x7f98b000efc0, xim=0x7f98b000c2c0 getX11InputMethodData 0x7f98b0019620, xim=0x7f98b000c2c0 getX11InputMethodData 0x7f98b0019620, xim=(nil) getX11InputMethodData 0x7f98b000f480, xim=0x7f98b8008140 getX11InputMethodData 0x7f98b000f480, xim=0x7f98b8008140 getX11InputMethodData 0x7f98b000efc0, xim=0x7f98b8008140 # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f98ecc7c9da, pid=31142, tid=31164 # When IM restarted, X11im value was recreated. It means NULL check was passed with new value. X11InputMethodData 0x7f98b000efc0 was created with xim=0x7f98b000c2c0. It crashes with new xim=0x7f98b8008140.

NOTE: This P4 bug will be retargeted to "13" in case this issue is still Unresolved by Mon, Dec 10 3am Pacific Time Mon Dec 10 (Pre Integration Testing deadline) to meet JDK 12 RDP1 (Dec 13th) milestone [1]. No more P4-P5 in JDK 12 beyond RDP1 in accordance with RDP1 definition [2]. [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-September/001984.html [2] http://openjdk.java.net/jeps/3

We found Notepad.jar demo didn't have this problem, because it depends on the calling order. Notepad.jar calls XMSeletion:initScreen() then XRegisterIMInstantiateCallback(). The testcase in webrev calls XRegisterIMInstantiateCallback() then XMSeletion:initScreen(). This problem is in the latter case.

Created webrev.01, which contains minimized patch and testcase. http://cr.openjdk.java.net/~tnakamura/8213183/webrev.01/