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 <[email protected]>
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.
