-
Bug
-
Resolution: Won't Fix
-
P4
-
None
-
5.0u3
-
other
-
linux
FULL JDK VERSION(S):
java version "1.5.0_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_03-b07)
Java HotSpot(TM) Client VM (build 1.5.0_03-b07, mixed mode)
OPERATING SYSTEM(S)
Redhat Enterprise Linux AS version 4 and 4+Update1
FULL JDK VERSION(S):
>java -version
java version "1.5.0_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_02-b09)
Java HotSpot(TM) Client VM (build 1.5.0_02-b09, mixed mode)
DESCRIPTION:
Steps to Recreate:
1) Set up RHEL4 with Japanese environment.
2) Launch the sample code, and then two JTextAreas will be open.
---MultiText.java-------------------------
import javax.swing.*;
class MultiText{
MultiText(){
JFrame f1,f2;
f1 = new JFrame(); f2 = new JFrame();
f1.getContentPane().add(new JTextArea(5,40));
f2.getContentPane().add(new JTextArea(5,40));
f1.pack(); f2.pack();
f1.setVisible(true); f2.setVisible(true);
}
public static void main(String[] args){
MultiText mt = new MultiText();
}
}
---------------------------------------
3) Repeat IM-on/off (pressing ctrl+space key) and focus change quickly.
Result:
Sometimes, IM-on/off wasn't affected. At the time, we couldn't input any characters.
If focus is changed once more, it seems a part of 'stored' input characters are swept out.
Expected Result:
IM can make response just after inputting.
Additional Information:
This problem seems to be a timing issue. These steps above are for easy reproduction.
The problem was able to recreate by normal speed operations, sometimes.
The problem occurs on XAWT, it doesn't on Motif Toolkit.
The same problem occurs when input many characters with focus change.
It seems the problem depends on IM. IIIMF Japanese, IIIMF Traditional Chinese
and xcin can be recreated at least. On the other hand, kinput doesn't.
IIIMF uses asynchronous communication of XIM protocol.
So, I doubt Java 5.0 doesn't treat asynchronous IMs properly.
According to my investigation, the problem might be caused by time lag between
focus change and XFilterEvent. It seems XFilterEvent is called by Java with
the parameter of the focused window. However, the parameter is sometimes too old.
###@###.### 2005-06-21 16:57:38 GMT
java version "1.5.0_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_03-b07)
Java HotSpot(TM) Client VM (build 1.5.0_03-b07, mixed mode)
OPERATING SYSTEM(S)
Redhat Enterprise Linux AS version 4 and 4+Update1
FULL JDK VERSION(S):
>java -version
java version "1.5.0_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_02-b09)
Java HotSpot(TM) Client VM (build 1.5.0_02-b09, mixed mode)
DESCRIPTION:
Steps to Recreate:
1) Set up RHEL4 with Japanese environment.
2) Launch the sample code, and then two JTextAreas will be open.
---MultiText.java-------------------------
import javax.swing.*;
class MultiText{
MultiText(){
JFrame f1,f2;
f1 = new JFrame(); f2 = new JFrame();
f1.getContentPane().add(new JTextArea(5,40));
f2.getContentPane().add(new JTextArea(5,40));
f1.pack(); f2.pack();
f1.setVisible(true); f2.setVisible(true);
}
public static void main(String[] args){
MultiText mt = new MultiText();
}
}
---------------------------------------
3) Repeat IM-on/off (pressing ctrl+space key) and focus change quickly.
Result:
Sometimes, IM-on/off wasn't affected. At the time, we couldn't input any characters.
If focus is changed once more, it seems a part of 'stored' input characters are swept out.
Expected Result:
IM can make response just after inputting.
Additional Information:
This problem seems to be a timing issue. These steps above are for easy reproduction.
The problem was able to recreate by normal speed operations, sometimes.
The problem occurs on XAWT, it doesn't on Motif Toolkit.
The same problem occurs when input many characters with focus change.
It seems the problem depends on IM. IIIMF Japanese, IIIMF Traditional Chinese
and xcin can be recreated at least. On the other hand, kinput doesn't.
IIIMF uses asynchronous communication of XIM protocol.
So, I doubt Java 5.0 doesn't treat asynchronous IMs properly.
According to my investigation, the problem might be caused by time lag between
focus change and XFilterEvent. It seems XFilterEvent is called by Java with
the parameter of the focused window. However, the parameter is sometimes too old.
###@###.### 2005-06-21 16:57:38 GMT