Hi Petr,
Please look at the updated webrev with comment explaining why additional
'if' clause is added:
http://cr.openjdk.java.net/~dmarkov/8024061/jdk9/webrev.01/
I have submitted a new bug JDK-8040248:
"Drag and drop between two components fails if performed quickly"
https://bugs.openjdk.java.net/browse/JDK-8040248
Regards,
Alexey.
On 10.04.2014 18:31, Petr Pchelko wrote:
Hello, Alexey.
Thank you for the clarification.
What actually happens is that native drag-and-drop operation completed already
whereas this drag-and-drop operation on EDT didn't even started yet. Does
throwing InvalidDnDOperationException look more appropriate than returning null
in this case?
No, I think it’s not good. As a workaround it’s better to not return the data
than to throw an exception. It would be really hard for the users to deal with
such an exception.
Please add some comment to the if clause to clarify what’s happening.
Otherwise the fix looks good to me.
With best regards. Petr.
10 апр. 2014 г., в 5:39 после полудня, Alexey Ivanov <[email protected]>
написал(а):
Hi Petr,
If the requested data flavor is DataFlavor.javaJVMLocalObjectMimeType, then transferable
is local to the JVM. It is stored to a static variable in
SunDropTargetContextPeer.setCurrentJVMLocalSourceTransferable(). When
processEnterMessage() is handled, its value is copied to instance variable
"local". The instance variable is cleaned by processExitMessage(), the static
variable is cleared by SunDragSourceContextPeer.cleanup().
If drag-and-drop operation is performed quickly, SunDragSourceContextPeer.cleanup() is
called when mouse button is released and *before* processEnterMessage() is called. So
when EDT finally handles MOUSE_ENTERED event and DropTargetListener.dragEnter() gets
called, "local" transferable is already null. The listener tries to get the
data from the transferable:
DropTargetDragEvent.getTransferable(), and then
Transferable.getTransferData(dataFlavor).
The dataFlavor has MIME type of DataFlavor.javaJVMLocalObjectMimeType, and
SunDropTargetContextPeer.currentJVMLocalSourceTransferable is already cleared.
The representationClass field of the DataFlavor object is set to
java.io.InputStream.class. So when SunDropTargetContextPeer.getNativeData()
executes it tries to cast the data object to java.io.InputStream to deserialize
the data but fails with the exception:
java.lang.ClassCastException: DnD$DropObject cannot be cast to
java.io.InputStream.
This exception is caught internally, and IOException is thrown as it failed to
get the data. At the same time, no IO should have occurred because a local
source was dragged, so this exception is rather unexpected.
What actually happens is that native drag-and-drop operation completed already
whereas this drag-and-drop operation on EDT didn't even started yet. Does
throwing InvalidDnDOperationException look more appropriate than returning null
in this case?
Sure, I'll submit a new bug for 9 to implement the proper fix.
Regards,
Alexey.
On 10.04.2014 12:52, Petr Pchelko wrote:
Hello, Dmitry.
Thank you for the detailed explanation of the issue.
I’m OK with this workaround as this should be back ported to 8u and 7u, but I
think we could try to provide a real fix in 9.
Could you please add some comment which shortly explains why the if clause was
added?
And could you also file a new bug for 9 so that we try to replace the
workaround with a real fix?
Thank you.
With best regards. Petr.
10 апр. 2014 г., в 12:18 после полудня, Alexey Ivanov
<[email protected]> написал(а):
Hello AWT team,
Could you please review the fix for jdk9:
bug: https://bugs.openjdk.java.net/browse/JDK-8024061
webrev: http://cr.openjdk.java.net/~dmarkov/8024061/jdk9/webrev.00/
Problem description:
Dragging and dropping an object from one panel to another very quickly causes
an exception.
Fix:
The fix addresses only the thrown exception.
The dragged object would not be moved.
Thanks,
Alexey.
