JDK-4516174 : couldn't display the national minority char for gb18030
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2001-10-18
  • Updated: 2002-11-11
  • Resolved: 2002-11-11
Related Reports
Duplicate :  
JDK-4705104 - Notepad hangs up when open uigur text in gb18030 locale.
Description
merlin b83
solaris 9

reproduce as fellow,
#java -jar Notepad.jar  //jdk's demo under jfc

Then open the attachment file uigur.txt etc, some file couldn't display, but if you using the native2ascii to convert it, it's can convert to utf8 success.

Attachment have four file which have support in solaris9 for chinese national minority, it's better to support it.
Comments
EVALUATION Font2DTest shows these characters are being displayed correctly, however looks like swing Notpad has problem to deal with them, sign to 2d for further investigation. ###@###.### 2001-10-23 I tried this out on java2d-lab-41 using the zh_CN_GB18030 locale. Both drawString and TextLayout can render these files just fine once they are converted into Unicode using InputStreamReader, and Font2DTest also handles them ok. On b85, for me at least, Notepad hangs when trying to load uigur.txt. If I convert it into UTF-8, and try to open it using Notepad with -Duser.encoding=UTF-8, I get sun.io.MalformedInputException. This seems even more severe than the original bug report. Since native2ascii can convert these files ok, and they display ok, I'm not sure what the problem is. Perhaps it is occuring when Notepad is opening the file using the GB18030 encoding? At any rate it doesn't seem to be a java2d problem. I'm reassigning this to swing. ###@###.### 2001-11-12 This problem is a result of a deadlock in the Swing text package. BasicTextUI.UpdateHandler.insertUpdate(), calls modelChanged() while it holds the document lock. modelChanged() calls setView() which calls removeAll() on the text component. This tries to get the AWTTreelock. Meanwhile, the document layout code causes a repaint() on the text component which first grabs the AWTTreelock and then tries to get the document lock. The solution is to change BasicTextUI.setView() to do the removeAll() on the text component immediately if on the event dispatching thread, or through an invokeLater otherwise. This is not a regression and has always been possible. It appears that the timing of this particular test case has revealed it. This is not a merlin showstopper and therefore must be downgraded in priority. ###@###.### 2001-11-16
16-11-2001