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