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" <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> 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.
