I can see the bug now at http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8136781 . Thanks again!
-- Eirik On 9/18/15, 3:01 PM, "macosx-port-dev on behalf of Eirik Bakke" <macosx-port-dev-boun...@openjdk.java.net<mailto:macosx-port-dev-boun...@openjdk.java.net> on behalf of eba...@mit.edu<mailto:eba...@mit.edu>> wrote: 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...@oracle.com<mailto:bug-report-daemon...@oracle.com>" <bug-report-daemon...@oracle.com<mailto:bug-report-daemon...@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.bylok...@oracle.com<mailto:sergey.bylok...@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.
