While trying to add setting clipboard content support to doh.robot, I encountered a very strange bug and spent several hours of trail and failure without going anywhere. I am using java 1.6 update 11 directly from Sun. Basically, I have two problems both of which are described here: copying HTML data to windows clipboard from java does not work, with the following symptoms

  1. when puting data into the clipboard with a RepresentationClass other than java.lang.String does not work properly with any applications (it is the same issue as described in a java bug report, which is supposed to be fixed in java 1.6 update 11)
  2. even if you do use java.lang.String as RepresentationClass, the pasted html only appear correctly in IE, not in safari (it contains extra garbage characters), nor in FF (nothing is pasted at all).

The problem as described in the mentioned webpage, is due to buggy support of windows HTML clipboard format in java. One workaround is suggested in the same article by modifying some internal stuffs in the supporting class in java with the source files available for download. However, the provided code fails to run against my java 1.6 (although it does compile fine), probably due to changed internal mechanisms.

Luckily, I tried to run the same code against the next version of java (1.7 provided by openjdk, still in development), and the paste works great in all three browsers. However, this java 1.7 does not provide a java plugin for Safari, nor google Chrome. (only java 1.6u10 and 1.6u11 support these two new comers)

In order to workaround this, I decided to backport the fix from java 1.7 to 1.6. I don’t want to re-compile the whole jre or jdk, I just want to fix this particular bug. The buggy code is in sun/awt/windows/HTMLSupport.class (in rt.jar under java installation folder).

After poking around in the java 1.7 source (grabbed from openjdk), it turns out that file does not exists. However, with some string searching in files, I found out that it is now defined in jdk\src\windows\classes\sun\awt\windows\WDataTransferer.java. After doing some renaming and such, I came up with a HTMLSupport.java source file (which is a direct port of the original file included in java 1.7 source). Aftering hijacking the builtin HTMLSupport, sure enough, everything works as expected in java 1.6 now.

A pre-compiled HTMLSupport jar is available for download, which should work in java 1.6 (may work in previous versions as well).

How to use this new HTMLSupport

If you intend to use java applet (as I do in this case), then hijacking (or BootClasspath trick) does not work for IE: even if you set -Xbootclasspath/p:\path\to\your\HTMLSupport.jar as the runtime parameter in java control panel for java applet, it does not work. It seems IE just simply refuses to look at that configuration and uses the default bootclasspath only.

Short of other workarounds, I do it the brutal force way: replace the original HTMLSupport.class file in rt.jar with the patched one (you can find this file in the jar, it is the only file in there). As this is intended to be used in a virtual machine whose sole purpose is to use doh.robot to run functional tests, so it is not that bad.

Thanks goes to all the authors of the articles mentioned in this post.

One thing to note: the original articile was written in 2003, more than five years ago, and this bug still exists in latest java stable release (which is 1.6 update 11).