<AWT Dev> [9] Review Request: JDK-8043513 Clipboard#getContents(Object) throws IOException

[Petr Pchelko]

> Closing this bug as Cannot Reproduce sounds like a good idea to me because we'll be able to re-open it if someone reproduces the issue again in the future.
I have filed https://bugs.openjdk.java.net/browse/JDK-8043807 for incorrect stack trace issue. This fix will go under that bug ID.
The original bug will be closed a cannot reproduce.

With best regards. Petr.

On May 23, 2014, at 1:15 AM, Anthony Petrov <anthony.petrov at oracle.com> wrote:

> Closing this bug as Cannot Reproduce sounds like a good idea to me because we'll be able to re-open it if someone reproduces the issue again in the future.
> 
> --
> best regards,
> Anthony
> 
> On 5/23/2014 1:01 AM, Petr Pchelko wrote:
>>> If I disable clipboard sharing in RDP it works without problems.
>>>> If I copy something into the clipboard after establishing the connection but before invoking the code it works without problems.
>>> 
>>> Petr, do you have any comments about this? Perhaps we should fix the stack trace origin issue under a separate bug id, and leave this bug open to address the original clipboard-shared-over-RDP issue?
>> I couldn’t reproduce this although I’ve tried really hard. I can fix stack trace origin under separate bugId, but this one I’m going close as cannot reproduce anyway.
>> 
>> More that that, looking at the code which throws the IOException I would say that this is more likely an RDP-client bug, not our bug. All we do here is call winapi function ::EnumClipboardFormats to get all available format and then call ::GetClipboardData for each format from that list. No place for a bug left here..
>> 
>> With best regards. Petr.
>> 
>> On May 23, 2014, at 12:52 AM, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>> 
>>> Interesting. I took a closer look at the bug report and found this:
>>> 
>>>> If I disable clipboard sharing in RDP it works without problems.
>>>> If I copy something into the clipboard after establishing the connection but before invoking the code it works without problems.
>>> 
>>> Petr, do you have any comments about this? Perhaps we should fix the stack trace origin issue under a separate bug id, and leave this bug open to address the original clipboard-shared-over-RDP issue?
>>> 
>>> --
>>> best regards,
>>> Anthony
>>> 
>>> On 5/22/2014 11:44 PM, Petr Pchelko wrote:
>>>> Hello, Sergey.
>>>> 
>>>>> Submitter complains about IOException itself, not about incorrect stack trace.
>>>> The IOException is fine.
>>>> It’s thrown from a different method (not as the stacktace states) and it’s OK by documentation.
>>>> Just the stack trace is “wrong”.
>>>> We can’t fix the IOException, because the clipboard was not ready and we can’t do anything about it.
>>>> 
>>>> With best regards. Petr.
>>>> On May 22, 2014, at 10:44 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>>>> 
>>>>> Hi, Petr.
>>>>> Submitter complains about IOException itself, not about incorrect stack trace.
>>>>> 
>>>>> On 5/22/14 1:39 PM, Anthony Petrov wrote:
>>>>>> Looks fine.
>>>>>> 
>>>>>> --
>>>>>> best regards,
>>>>>> Anthony
>>>>>> 
>>>>>> On 5/21/2014 4:27 PM, Petr Pchelko wrote:
>>>>>>> Hello, AWT Team.
>>>>>>> 
>>>>>>> Please review the fox for the issue:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043513
>>>>>>> The fix is available at:
>>>>>>> http://cr.openjdk.java.net/~pchelko/9/8043513/webrev/
>>>>>>> 
>>>>>>> The problem:
>>>>>>> When we fetch all contents from the clipboard we catch IOException and store it for later.
>>>>>>> In case we would then need the data which caused the exception the cached exception would be rethrown.
>>>>>>> But the stack trace shows where the exception was created, not thrown. Wrapping it helps to
>>>>>>> eliminate the misunderstanding.
>>>>>>> 
>>>>>>> With best regards. Petr.
>>>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Best regards, Sergey.
>>>>> 
>>>> 
>>