JDK-4718897 : Clipboard context does not work correctly on Solaris
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.1
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_7
  • CPU: sparc
  • Submitted: 2002-07-23
  • Updated: 2003-04-12
  • Resolved: 2002-09-06
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
1.4.2 mantisFixed
Related Reports
Relates :  
JDK-4480282 - Arabic native-to-Swing cut & paste is broken.
Relates :  
JDK-4767165 - Copy&Paste from dtterm to Swing text components on Solaris/ja doesn't work
Relates :  
JDK-4393099 - Need CharToByte and ByteToChar converters for x-compound-text encoding
Relates :  
JDK-4934597 - NPE pasting unprintable chars into text boxes
Description
The text String set to clipboard by java program does not seem to
work correctly.

1. Reproduce
 
 1) Compile the attached program as follows.
   javac -encoding SJIS ClipboardDemo.java

 2) execute the program
   java ClipboardDemo

 3) Open the text editor of CDE and press the "Paste" Key

 --> You will see the text string is not copied correctly.

2. Confiration

   SunOS goedel 5.7 Generic_106541-15 sun4u sparc SUNW,Ultra-60

3. Note

   This happens with Merlin-rc.

java version "1.4.1-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-rc-b16)
Java HotSpot(TM) Client VM (build 1.4.1-rc-b16, mixed mode)

  However, with 1.3.1_03, this works well.

java version "1.3.1_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03)
Java HotSpot(TM) Client VM (build 1.3.1_03-b03, mixed mode)

 So, I recommend to try in 1.3.1_03 first.


2002-07-23
=========================================================================
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis mantis-b02 FIXED IN: mantis mantis-b02 INTEGRATED IN: mantis mantis-b02 VERIFIED IN: mantis
14-06-2004
PUBLIC COMMENTS .
10-06-2004
SUGGESTED FIX Name: dsR10078 Date: 08/09/2002 Disable COMPOUND_TEXT support for inter-client text transfer by default. Add support for UTF8_STRING. --- flavormap.properties Fri Aug 2 18:04:59 2002 *************** *** 60,66 **** # See java.awt.datatransfer.DataFlavor.selectBestTextFlavor for a list of # text flavors which support the charset parameter. ! COMPOUND_TEXT=text/plain;charset=x-compound-text;eoln="\n";terminators=0 TEXT=text/plain;eoln="\n";terminators=0 STRING=text/plain;charset=iso8859-1;eoln="\n";terminators=0 FILE_NAME=application/x-java-file-list;class=java.util.List --- 60,76 ---- # See java.awt.datatransfer.DataFlavor.selectBestTextFlavor for a list of # text flavors which support the charset parameter. ! UTF8_STRING=text/plain;charset=UTF-8;eoln="\n";terminators=0 ! ! # The COMPOUND_TEXT support for inter-client text transfer is disabled by ! # default. The reason is that many native applications prefer this format over ! # other native text formats, but are unable to decode the textual data in this ! # format properly. This results in java-to-native text transfer failures. ! # To enable the COMPOUND_TEXT support for this JRE installation uncomment ! # the line below. ! ! # COMPOUND_TEXT=text/plain;charset=x-compound-text;eoln="\n";terminators=0 ! TEXT=text/plain;eoln="\n";terminators=0 STRING=text/plain;charset=iso8859-1;eoln="\n";terminators=0 FILE_NAME=application/x-java-file-list;class=java.util.List ###@###.### 2002-08-09 ======================================================================
09-08-2002
WORK AROUND Name: dsR10078 Date: 07/25/2002 Remove the mapping for COMPOUND_TEXT format from lib/flavormap.properties file in your JRE installation: --- flavormap.properties Tue Jul 24 20:28:15 2001 *************** *** 60,66 **** # See java.awt.datatransfer.DataFlavor.selectBestTextFlavor for a list of # text flavors which support the charset parameter. ! COMPOUND_TEXT=text/plain;charset=x-compound-text;eoln="\n";terminators=0 TEXT=text/plain;eoln="\n";terminators=0 STRING=text/plain;charset=iso8859-1;eoln="\n";terminators=0 FILE_NAME=application/x-java-file-list;class=java.util.List --- 60,66 ---- # See java.awt.datatransfer.DataFlavor.selectBestTextFlavor for a list of # text flavors which support the charset parameter. ! # COMPOUND_TEXT=text/plain;charset=x-compound-text;eoln="\n";terminators=0 TEXT=text/plain;eoln="\n";terminators=0 STRING=text/plain;charset=iso8859-1;eoln="\n";terminators=0 FILE_NAME=application/x-java-file-list;class=java.util.List ###@###.### 2002-07-25 ======================================================================
25-07-2002
EVALUATION The test case tries to copy a string that contains Japanese KATAKANA translation for the word "test", i.e., \u30C6\u30B9\u30C8, into the system clipboard. As the problem description says, it works fine on jdk 1.3.1, but fails on jdk 1.4 beta, where those Japanese characters get garbled on pasting. Transferring to Drag & Drop. ###@###.### 2002-07-23 It's far too late for Hopper: I'll commit this to Mantis since Hitachi is reporting it as a regression in 1.4. ###@###.### 2002-07-23 Name: dsR10078 Date: 07/24/2002 This regression was introduced with the Compound Text support implemented in 1.4. Currently COMPOUND_TEXT is the preferred native format for text transfer between java and native applications on X11. However, text transfer can fail because of the bugs in Solaris implementation of COMPOUND_TEXT support. Some of these bugs are documented under bug ids 4502606, 4506640, 4521799, 4528767, 4528768. A similar problem with java-to-native text transfer is documented in 4480282. A simple native application that dumps the selection contens indicates that the data exported by the Java application to the CLIPBOARD selection is the following byte sequence: 116(0x74) 101(0x65) 115(0x73) 116(0x74) 27(0x1B) 36(0x24) 40(0x28) 65(0x41) 37(0x25) 70(0x46) 37(0x25) 57(0x39) 37(0x25) 72(0x48) 27(0x1B) 40(0x28) 66(0x42) 27(0x1B) 45(0x2D) 65(0x41) 116(0x74) 101(0x65) 115(0x73) 116(0x74) This sequence constitutes the string "test\u30C6\u30B9\u30C8test" translated from Unicode to Compound Text. So, the cause of the problem is that the native text editor fails to interpret the Compound Text data properly. The workaround is to disable Compound Text support in JRE. ###@###.### 2002-07-24 ======================================================================
24-07-2002