JDK-6707023 : Chinese Characters in JTextPane Cause Pane to Hang
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 5.0u16,6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2008-05-26
  • Updated: 2011-02-16
  • Resolved: 2009-02-19
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.
Other Other Other Other JDK 6 JDK 7
5.0u16-crevFixed 5.0u17-crevFixed 5.0u18-revFixed 5.0u19Fixed 6u11-revFixed 7 b48Fixed
Description
FULL PRODUCT VERSION :
Intel Dual-Core CPU

ADDITIONAL OS VERSION INFORMATION :
Windows XP Professional, 2002, Service Pack 2

EXTRA RELEVANT SYSTEM CONFIGURATION :
Intel Dual-Core CPU

A DESCRIPTION OF THE PROBLEM :
Enter a detailed description of the problem. Please describe only one problem per report. For multiple problems, file a separate report for each one.

Typing Chinese characters into a JTextPane causes a string of exceptions to occur and the JTextPane itself freezes.

This issue can be replicated by compiling the sample application provided by Sun at the following URL and embedding the application into an applet:

http://java.sun.com/docs/books/tutorial/uiswing/examples/components/index.html#TextSamplerDemo

This issue can also be replicated using JRE 1.5 and JRE 1.6 update 10 beta.

Note that this issue only occurs on dual core machines.

We had originally seen this problem in our own application and raised this a bug with you (review ID: 1234725).

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :

1. Download the code provided by Sun at the following URL:

http://java.sun.com/docs/books/tutorial/uiswing/examples/components/index.html#TextSamplerDemo

2. Create a simple class to package this application as an applet and a simple HTML page to load the applet (see the source code packaged with this report).

3. Open the webpage to launch the application.

4. Remove the text in the bottom-right editing pane.

5. Change the input language to the following:

Language: Chinese (Taiwan)
Keyboard: Chinese (Traditional) - Quick

6. Use a combintation of the A, S, D, F and enter keys to generate Chinese characters. Randomly click before/after previous characters and continue typing. Generally within 2 minutes a mass of exceptions will occur and the JTextPane will hang.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Typing Chinese characters will not cause exceptions and will not hang the text pane.
ACTUAL -
Typing Chinese characters causes exceptions and hangs the text pane.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Attached Seperatly

REPRODUCIBILITY :
This bug can be reproduced always.

Comments
SUGGESTED FIX --- a/src/windows/classes/sun/awt/windows/WInputMethod.java Tue Aug 26 16:31 :13 2008 +0400 +++ b/src/windows/classes/sun/awt/windows/WInputMethod.java Tue Aug 26 20:53 :28 2008 +0400 @@ -548,11 +548,15 @@ public class WInputMethod extends InputM public void inquireCandidatePosition() { + Component source = getClientComponent(); + if (source == null) { + return; + } // This call should return immediately just to cause // InputMethodRequests.getTextLocation be called within // AWT Event thread. Otherwise, a potential deadlock // could happen. - java.awt.EventQueue.invokeLater(new Runnable() { + Runnable r = new Runnable() { public void run() { int x = 0; int y = 0; @@ -573,7 +577,9 @@ public class WInputMethod extends InputM openCandidateWindow(awtFocussedComponentPeer, x, y); } - }); + }; + WToolkit.postEvent(WToolkit.targetToAppContext(source), + new InvocationEvent(source, r)); } // java.awt.Toolkit#getNativeContainer() is not available
26-08-2008

EVALUATION I couldn't reproduce the problem on my WinXP desktop so far... After a quick look to the code I have found a single suspicious place in WInputMethod.java: public void inquireCandidatePosition() { ... java.awt.EventQueue.invokeLater(new Runnable() { public void run() { ... } }); } This code is obviously must be rewritten because EventQueue methods know nothing about AppContexts, and the Runnable may be executed on wrong EDT.
26-08-2008

EVALUATION The reason for this behavior is that in some cases input events are posted to several AWT threads at once, and eventually all these threads call to Swing attempting to do re-layout at the same time. Swing is not thread-safe, so it messes up its internal structures which leads to spurious NPEs, deadlocks etc. preventing an applet from responding. Re-assigning to the AWT team.
21-08-2008