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

[Anthony Petrov]

Thanks, Petr. The fix for the stack trace issue still looks fine to me.

--
best regards,
Anthony

On 5/23/2014 1:19 AM, Petr Pchelko 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.
> 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.
>>>>>>
>>>>>
>>>
>