JDK-6184471 : Japanese Input tool does not work properly for JTextField
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt:i18n
  • Affected Version: 1.2.0,1.4.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux,solaris_7
  • CPU: x86,sparc
  • Submitted: 2004-10-26
  • Updated: 2010-08-19
  • Resolved: 2004-12-13
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 6
6 betaFixed
Related Reports
Duplicate :  
Relates :  
Description
Disclaimer: Sorry I didnot find proper Category to put this bug in BugSter
           
           It is Swing  problem with Japanese input tool( on SUSE9.0 
           jdk1.4.2_01 and jdk 1.5.0_01-ea)
 

IHAC who encounters a problem

kinput2 doesnot work problem for Swing's JTextField,
but it works fine for other software 's Text Field(For Example, Mozilla)

To reproduce the problem
You have to 
1) in SUSE9.0 installed required Japanese fonts rpms

2) start you cannaserver (by typing canaserver)

3) start your japanese input tool kinpu2 against canaserver (by typing kinpu2 -canna)

in attachments

1) Bugreport.txt described the detailed problem, required locale setting for OS
   requried japanese fonts rpm, instruction to reproducing testcase.
  
2) KeyboardTest.java is java testcase code

3) KeyboardTest.class is compile class file
###@###.### 10/26/04 11:32 GMT


From the attachments:


Bugreport.txt:

Summary: Input method gets inactive when switching between entry fields
================================================================================================

Operating systems: 
==================
Linux       : Linux ls3614 2.4.21-243-default #1 Thu Aug 12 15:22:14 UTC 2004 i686 i686 i386 GNU/Linux
Distribution: SuSE 9.0 but observable with all other tested distributions 

Java version:
=============
java version "1.4.2_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_01-b06)
Java HotSpot(TM) Client VM (build 1.4.2_01-b06, mixed mode)

java version "1.5.0_01-ea"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_01-ea-b01)
Java HotSpot(TM) Client VM (build 1.5.0_01-ea-b01, mixed mode)

and anything below and in between

System setup:
=============
J2RE 1.4.2

Locale :
LANG=ja_JP.eucJP
LC_CTYPE=ja_JP.eucjp
LC_NUMERIC=de_DE@euro
LC_TIME=de_DE@euro
LC_COLLATE=de_DE@eurov
LC_MONETARY=de_DE@euro
LC_MESSAGES=en_US
LC_PAPER="ja_JP.eucJP"
LC_NAME="ja_JP.eucJP"
LC_ADDRESS="ja_JP.eucJP"
hLC_TELEPHONE="ja_JP.eucJP"
LC_MEASUREMENT="ja_JP.eucJP"
LC_IDENTIFICATION="ja_JP.eucJP"
LC_ALL=

XMODIFIERS=@im=kinput2

kinput2 as input method frontend
cannaserver as conversion backend

processes:

wnn       1198     1  0 Oct19 ?        00:00:00 /usr/sbin/cannaserver -u wnn -r /var/lib/canna
d024679  11682 11680  0 10:36 pts/9    00:00:00 kinput2 -canna

Description:
============

After activating the input method on an entry field with Ctrl-SPACE
and entering and commiting text, a focus change to another entery
field in the same frame deactivates the input method. Under 1.4.2 the
input methods state indicator is not correctly updated, under 1.5.0_01
the indicator goes off. To further type text into the second field the
input method has to be activated again, preventing fluent data entry.

Reproduction: 
============= 

JRE 1.4.2

Install the necessary fonts from xtt-fonts-xxx.rpm setup the required
japanese locale, cannaserver and kinput2

start the test program : java IMTest.FontTest

Click into the first entry field, activate the input method with
Ctrl-SPACE.  Note the IM indicator showing the active script. Enter ka
and commit the text.

Press TAB to focus the second entry field. Note IM indicator still
indicates the IM is active.

Enter ka and note that input is not sent to the IM frontend.

Press Ctrl-SPACE and note that the IM indicator does not change.

Enter ka and note the IM is active again.


KeyboardTest.java:

package IMTest;

import java.awt.GraphicsConfiguration;
import java.awt.event.KeyEvent;
import java.io.ByteArrayInputStream;
import java.io.InputStreamReader;
import java.util.Locale;

import javax.swing.JFrame;
import javax.swing.JMenu;
import javax.swing.JMenuBar;
import javax.swing.JMenuItem;
import javax.swing.JTextField;

public class KeyboardTest extends JFrame
{
    private JTextField textField = null;
    private JTextField textField2 = null;
    private JMenuBar   menuBar   = new JMenuBar();
    private JMenu      fileMenu  = new JMenu("File");
    private JMenuItem      menuItem  = new JMenuItem("Exit");
    public KeyboardTest()
    {
        super();
        init();
    }

    public KeyboardTest(GraphicsConfiguration gc)
    {
        super(gc);
        init();
    }

    public KeyboardTest(String title)
    {
        super(title);
        init();
    }

    public KeyboardTest(String title, GraphicsConfiguration gc)
    {
        super(title, gc);
        init();
    }

    public void init()
    {
        fileMenu.add(menuItem);
        menuBar.add(fileMenu);
        this.setJMenuBar(menuBar);
        this.getContentPane().setLayout(null);
        this.setSize(250,200);

        textField = new JTextField();
        textField.setLocation(10,10);
        textField.setSize(200,20);
        
        textField2 = new JTextField();
        textField2.setLocation(10,30);
        textField2.setSize(200,20);
        
        this.getContentPane().add(textField);
        this.getContentPane().add(textField2);

        this.setVisible(true);
        this.printInfoHeader();
    }
    
    
    public void printInfoHeader()
    {
        Locale locale = Locale.getDefault();
        System.out.println("============================================================");
        System.out.println("Operating system: " + System.getProperty("os.name")+ ", " + System.getProperty("os.version"));
        System.out.println("Java VM version : " + System.getProperty("java.vm.version"));
        System.out.println("System locale   : " + locale);
        System.out.println("Default encoding: " + (new InputStreamReader(new ByteArrayInputStream(new byte[0])).getEncoding()));

        System.out.println("============================================================");
    }

    public static void main(String[] args)
    {
        //JFrame.setDefaultLookAndFeelDecorated(true);
        JFrame frame = new KeyboardTest("Keyboard Test");
     }
}
###@###.### 10/28/04 17:24 GMT

Comments
SUGGESTED FIX Refer to the i18n team webrevs for the completed suggested fix. The location is http://javaweb.sfbay/intl/mustang/webrevs/6184471 ###@###.### 2004-11-30 18:30:07 GMT ###@###.### 2004-12-10 17:55:45 GMT
10-11-2004

EVALUATION Here is the root cause of the issue. The following description applies to Unix/Linux platforms only. Assume we have 2 text components T1 & T2(active client or passive client) which share the same InputContext. When the focus is switched from T1 to T2. Here is what happened. FocusEvent.FOCUS_LOST is first sent to T1 and then FocusEvent.FOCUS_GAINED sent to T2. The first event causes T1 to call X11InputMethod.deactivate which calls XUnsetICFocus to T1. The second event first tries to activate the input method and then calls endComposition. If the user types some chinese/japanese character, X11InoputMethod.endComposition will set isCompositionEnabled flag to true. The implementation of X11InputMethod.endComposition tries to delay calling XSetICValues until the X11InputMethod.activate is called on the new component. After endComposition called, deactivateInputMethod is called which causes the input context to be set to intial state again. And when activateInputMethod is called to actiavte the input method for the new focused component, it first tries to call "X11InputMethod.resetXICifneeded", but this call fails to set the composition state to XNPreeditState since the input context has been set to initial state. And this is why we see the composition state is not carried to T2. So the fix is to call resetXICifneeded after XSetICFocus is called on T2 which properly sets the input context of the input method. Refer to "suggested fix" section for the fix. The same problem could be seen on Cinnabar platform as well. But even with the fix, it still does not work due to XSetICValues(inputContext, XNPreeditState, XIMPreeditEnable, NULL) is not fully operational on SuSE based XIM implementation. In which case, we can't do much. ###@###.### 2004-11-10 03:33:54 GMT During the test of the fix, I found some other underlying problems. Trying to fix them in one shot. ###@###.### 2004-11-23 18:21:07 GMT ###@###.### 2004-11-23 18:21:16 GMT The problems I have seen after the change on Wnn6 has been reported to Solaris xserver team(Bug 6200281). Atok8 also shows some wierd problem when the focus gets back. Bug 6201359 is reported for this. ###@###.### 2004-11-29 23:37:21 GMT ###@###.### 2005-03-03 23:14:57 GMT
10-11-2004