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.scherba...@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
>>
>
