Hello, Oleg. The fix looks fine to me.
Just one comment: > 1. In drop target code, in SunDropTargetContextPeer.getTransferData() method > inputStream was closed in finally scope but was not yet used in client code > (indirectly). Just its reference stored for the future in > DataTransferer.getInstance().translateStream() call. I think we should file a separate bug for 9 to investigate this case in more details. In case the DataFlavor representation class in not an InputStream closing the underling stream would be completely fine and correct. So we should try to separate the cases where the representation class in an InputStream and not InputStream and close the underling stream for the latter case. This would be too risky to do in 8, but we could do it in 9. With best regards. Petr. On 28.10.2013, at 2:41, Oleg Pekhovskiy <oleg.pekhovs...@oracle.com> wrote: > Hi all, > > please review the fix > http://cr.openjdk.java.net/~bagiras/8027151.1/ > for > https://bugs.openjdk.java.net/browse/JDK-8027151 > > This issue appeared after the changes made for JDK-7075105. > There were two problems: > 1. In drop target code, in SunDropTargetContextPeer.getTransferData() method > inputStream was closed in finally scope but was not yet used in client code > (indirectly). Just its reference stored for the future in > DataTransferer.getInstance().translateStream() call. > > 2. In drop target code, in DataTransferer.translateStream() there was no > String object handler (it was moved from > DataTransferer.translateBytesOrStream() only to > DataTransferer.translateBytes() method). > > Thanks, > Oleg
