Bug: SystemFlavorMap.addFlavorForUnencodedNative ineffective on MacOS

[Mike Swingler]

Excellent question. I honestly don’t know, since the addition of that section was part of the original Java 1.4 implementation bring-up on Cocoa (and shares no lineage with the Carbon-based 1.3). While there were bug fixes in the DnD machinery around that area, the flavor map was a section that “just worked”. As far as I know, the point of the “JAVA_DATAFLAVOR:” prefix was only route serialized Java objects through the NSPasteboard during a drag-and-drop operation. Presumably nobody bothered copying/pasting more complex data types than the ones we provided translators for above (or if they did, the bugs never hit our threshold for investigating).

I’m sorry I’m not able to explain why it is the way it is, but hopefully the historical context will be helpful.

Regards,
Mike Swingler
Apple Inc.

> On Oct 9, 2015, at 7:00 AM, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
> 
> 
>  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
>> 
>