Bug: SystemFlavorMap.addFlavorForUnencodedNative ineffective on MacOS

[Eirik Bakke]

Hi, Sergey.

I've filed the bug and received review ID JI-9024567 for now. Thanks!

-- Eirik

On 9/18/15, 2:58 PM, "Bug-Report-Daemon_WW at ORACLE.COM"
<Bug-Report-Daemon_WW at ORACLE.COM> wrote:

>Dear Java Developer,
>Thank you for reporting this issue.
>
>We are evaluating this report and have assigned it a Review ID:
>JI-9024567. In the event this report is determined to be a defect or
>enhancement request, it will be referenced with a new Bug ID and will be
>listed on Bugs.java.com. For other related issues, please visit our Bug
>Database at http://bugs.java.com.
>
>We try to process all newly posted bugs in a timely manner, but make no
>promises about the amount of time in which a bug might be fixed. If the
>issue just reported could have a major impact on your project, consider
>using one of the technical support offerings available at Oracle Support.
>
>Regards,
>Java Community Developer Support
>



On 9/18/15, 2:35 PM, "Sergey Bylokhov" <Sergey.Bylokhov at oracle.com> wrote:

>Hi, Eirik.
>Thanks for report! Please file a new bug at
>http://bugreport.sun.com/bugreport , don't forget to add a steps to
>reproduce, then send me a bugid.
>
>
>On 18.09.15 21:18, 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(myN
>>ewFlavor, (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
>>
>
>
>-- 
>Best regards, Sergey.