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

[Sergey Bylokhov]

Hi, Petr.
The fix looks good to me too.

On 5/23/14 1:20 AM, Anthony Petrov wrote:
> 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.
>>>>>>>
>>>>>>
>>>>
>>


-- 
Best regards, Sergey.