Some applications seem to reserve a fixed size buffer for copying text to the clipboard, to which the null terminated string is written.

For example, some debug output of a copy from an application with a fixed 30 byte buffer size and the string "Hello World":
[text/plain]: "Hello World O W B R E A K" [72,101,108,108,111,32,87,111,114,108,100,0,79,0,87,0,66,0,82,0,69,0,65,0,75,0,0,0,0,0,]
[ms-stuff/oem-text]: "java.nio.HeapByteBuffer[pos=0 lim=31 cap=31]" [72,101,108,108,111,32,87,111,114,108,100,0,79,0,87,0,66,0,82,0,69,0,65,0,75,0,0,0,0,0,0,]
[ms-stuff/locale]: "java.nio.HeapByteBuffer[pos=0 lim=4 cap=4]" [7,4,0,0,]

Pasting to a text field results in "Hello World O W B R E A K", as the earlier null terminator is ignored.

I propose the following changes when copying from the buffer:
diff --git a/modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinSystemClipboard.java b/modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinSystemClipboard.java
index 047807c7e4..2e9582d943 100644
--- a/modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinSystemClipboard.java
+++ b/modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinSystemClipboard.java
@@ -251,7 +251,14 @@ class WinSystemClipboard extends SystemClipboard {
             if (TEXT_TYPE.equals(mime) || URI_TYPE.equals(mime)) {
                 try {
                     // RT-16199 - internal Windows data null terminated
- return new String(data, 0, data.length - 2, defaultCharset);
+ int nullTerm = data.length - 2;
+ for (int i = 0; i < data.length; i += 2) {
+ if (data[i] == 0) {
+ nullTerm = i;
+ break;
+ }
+ }
+ return new String(data, 0, nullTerm, defaultCharset);
                 } catch (UnsupportedEncodingException ex) {
                     //never happen
                 }