Bug: SystemFlavorMap.addFlavorForUnencodedNative ineffective on MacOS

[Alexander Scherbatiy]

   Hello Mike,

   The initial Clipboard support in CToolkit in Mac OS X [1] recognizes 
only NSPasteboard data types that have "JAVA_DATAFLAVOR:" prefix:
---------------------
+jlong indexForFormat(NSString *format) {
...
+    // If we don't recognize the format, but it's a Java "custom" 
format register it
+    if (returnValue == -1 && ([format hasPrefix:@"JAVA_DATAFLAVOR:"]) ) {
+        returnValue = registerFormatWithPasteboard(format);
+    }
---------------------

   What was the reason that Java supports only these java custom formats 
on Mac OS X?

   See also issue [2]:  JDK-8136781 
SystemFlavorMap.addFlavorForUnencodedNative is ineffective on MacOS

   [1] 
http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/dfe77a31519f
   [2] https://bugs.openjdk.java.net/browse/JDK-8136781

   Thanks,
   Alexandr.

On 9/18/2015 9:18 PM, Eirik Bakke wrote:
> Hi, macosx-port-dev.
>
> There seems to be a bug in the MacOS implementation underlying SystemFlavorMap.addFlavorForUnencodedNative. Where would the best place to report this be? Is this the relevant mailing list?
>
> The bug report follows:
>
> My Java application allows users to paste selections from Microsoft Excel. The data is retrieved using Excel's binary BIFF8 format rather than in plain text format in order to reliably detect date formatting, preserve numerical precision, and such. On Windows, getting to the relevant clipboard InputStream can be achieved by calling SystemFlavorMap.addUnencodedNativeForFlavor to map a new DataFlavor to a native data type identifier. On MacOS, however, there seems to be a bug that renders SystemFlavorMap.addUnencodedNativeForFlavor ineffective.
>
> Looking at the JDK source code, the bug seems to be that sun.lwawt.macosx.CDataTransferer.registerFormatWithPasteboard is never called when SystemFlavorMap.addUnencodedNativeForFlavor/ addFlavorForUnencodedNative is used to register a new native clipboard data format. This leads Java_sun_lwawt_macosx_CClipboard_getClipboardFormats in macosx/native/sun/awt/CClipboard.m to never return formats of the new type, because indexForFormat (in CDataTransferer.m) will always return -1.
>
> The observation above lead me to a workaround for the bug, which is to call sun.awt.datatransfer.DataTransferer.getInstance().getFormatsForFlavor(myNewFlavor, (SystemFlavorMap) SystemFlavorMap.getDefaultFlavorMap()) once after first mapping the flavor using addUnencodedNativeForFlavor and addFlavorForUnencodedNative. This works because the call to getFormatsForFlavor forces DataTransferer.getFormatForNativeAsLong to be called with the new native data type identifier, which in turn causes registerFormatWithPasteboard to be called in CDataTransferer.m. I'm worried that the workaround will cease to work in the future, however, since it relies on an obscure side-effect of a method in a private API from the sun.awt package.
>
> I've assembled a minimal example here: https://gist.github.com/eirikbakke/e8022f9f8d26c28eecd7
>
> -- Eirik
>