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

[Anthony Petrov]

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