JDK-4767165 : Copy&Paste from dtterm to Swing text components on Solaris/ja doesn't work
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.2
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: linux,solaris_9
  • CPU: x86,sparc
  • Submitted: 2002-10-23
  • Updated: 2008-12-18
  • Resolved: 2008-12-18
Related Reports
Relates :  
JDK-4718897 - Clipboard context does not work correctly on Solaris
Description
[Tested with Mantis b03 on Solaris Sparc ja locale]

Copying Japanese characters from dtterm window and pasting them to Swing text componets on Solaris Ja locale using Copy key/Paste key or dtterm's menu(Edit->Copy/swing application's menu for Pasting), the chacacters can't be displayed on the componetns.

I saw the problem on Solaris 9 and 8 Sparc ja_JP.euc locale using Notepad demo, Stylepad demo and other swing application(JTextArea).

Trying the same test for ASCII characters, it works fine.

===========================================================================
To reproduce, 

1. Launch Notepad demo on $JAVAHOME/demo/jfc/Notepad.

2. Launch dtterm and cat the attached file.
(It includes some Japanese characters \u3042 \u3044 \u3046 \u3048 \u304a \u30a2 \u30a4 \u30a6 \u30a8 \u30aa)

3. Highlight the characters and copy the characters using Copy key(or dttemrs  Edit->copy menu).

4. Paste them onto Notepad demo window using Paste key(or Notepad's Edit->Paste menu)

5. The characters are not displayed on the demo window.

===========================================================================

I tried copying the characters from dtpad and tried to paste them on the swing componets, this problem is not reproducible and the characters are displyaed properly.

This is not reproducible with Hopper FCS and 1.4.1_01.
This is reproducible with Mantis b02.

There is bug 4718897 which was fixed and verified in Mantis.
(Synopsis: Clipboard context does not work correctly on Solaris)
This is reproducible with Hopper FCS and not reproducible with Mantis.

I suspect 4718897's fix affects the problem.
For 4718897's fix, flavormap.properties was changed from Hopper.
(Please see Suggested Fix of the bug report for the detail.)
In trying the steps above with Mantis b03, I replaced the flavormap.properties with Hopper's one and tried the test, this problem was not reproducible.
So I think that 4718897's fix cause this problem.
Therefore, I set drag&drop as Subcategory as same as 4718897.


----------------------------------------------------------------------------
Correction for a description above, 
 "I saw the problem on Solaris 9 and 8 Sparc ja_JP.euc locale...."
 =======> not ja_JP.euc, ja locale

I confirmed also that this is reproducible on ja_JP.PCK and ja_JP.UTF-8.

###@###.### 2002-10-23
----------------------------------------------------------------------------
Comments
WORK AROUND Name: dsR10078 Date: 10/23/2002 1.Uncomment the line starting with COMPOUND_TEXT in the lib/flavormap.properties in your JRE installation to reenable COMPOUND_TEXT support. Note that this change will affect all Java applications run on this single JRE installation. 2.For dtterm on Solaris: use PRIMARY selection instead of CLIPBOARD to transfer text data to Java applications. ###@###.### 2002-10-23 ======================================================================
23-10-2002
EVALUATION Name: dsR10078 Date: 10/23/2002 When the japanese text is selected in dtterm and copied with Copy key or Edit->Copy in dtterm's menu, dtterm acquires the ownership of the CLIPBOARD selection and declares that it can provide the text data only for COMPOUND_TEXT target. The text cannot be pasted in Java application as the fix for 4718897 disables COMPOUND_TEXT support. Note that it may be possible to transfer the text from dtterm to a Java app via the PRIMARY selection. Select the text in dtterm, switch to the Notepad and press the middle mouse button to paste. The difference is that Solaris dtterm is implemented so that when it acquires the ownership of the PRIMARY selection it declares that the text data can be requested in COMPOUND_TEXT, STRING and TEXT, and Java application successfully uses TEXT format to retrieve the selected text. The bug is not reprodicuble with dtpad, since dtpad provides the text data in COMPOUND_TEXT, STRING and TEXT for both PRIMARY and CLIPBOARD selections. On Linux, i reproduced the described behavior with the GNOME terminal version 1.4.0.4. The reason is that when japanese text is selected the terminal acquires the PRIMARY selection ownership and declares that the text can be retrieved using the following targets: UTF-8, COMPOUND_TEXT, TEXT and STRING. The Java application requests the data for TEXT target and the terminal returns text in COMPOUND_TEXT format, so the Java app fails to decode the text properly and displays malformed characters. This is not a terminal bug, but a deficiency in the Java data transfer subsystem, since ICCCM defines TEXT target as "the text in the owner's choice of encoding". Another issue is that the terminal uses UTF-8 which is not a standard target name. UTF8_STRING should be used instead. On the same Linux machine I checked if the bug manifests with xterm (version XFree86 4.2.0(165)) and was unable to reproduce the bug. The reason is that unlike the terminal, xterm uses the standard UTF8_STRING target to represent text data in UTF-8 encoding. With the fix for 4718897, Java supports this target and so successfully retrieves and decodes the text. Unfortunatelly, it is not acceptable to fix this problem by uncommenting COMPOUND_TEXT line in lib/flavormap.properties, as it would reintroduce numerous problems caused by broken COMPOUND_TEXT support for some locales in Solaris libraries. As a workaround we could suggest to uncomment this line in your JRE installation, as it might work correctly in your environment. ###@###.### 2002-10-23 ======================================================================
23-10-2002