Hi Oleg,
I'm not an expert in this code so I may ask some silly questions.
I'm OK with the change #2.
Regarding #1: could you please clarify what code is responsible for
closing the stream now, after your fix? Is this documented/enforced
anywhere (i.e. a finally{} block or something)? Have you run any
regression tests to make sure this change doesn't introduce any memory
leaks? Why was this not a problem before that we decided to fix this
particular piece now, so late in the release?
--
best regards,
Anthony
On 10/28/2013 02:41 AM, Oleg Pekhovskiy 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
