On Wed, 8 Nov 2023 09:28:13 GMT, songpv-imt <d...@openjdk.org> wrote:
>> The root cause of the bug is because mousePress() method is invoked before >> mouseMove() event is completely processed causing the drag & drop behavior >> not being able to be recognized properly. This in turn makes the method >> dragSourceListener.isDropFinished() returns false and fail the test. To fix >> this, setAutoWaitForIdle(true) and Thread.Sleep is called to make sure the >> mouseMove() event is processed completely before moving to execute the >> mousePress() method. >> >> JBS issue: [JDK-8317287](https://bugs.openjdk.org/browse/JDK-8317287) > > songpv-imt has updated the pull request incrementally with one additional > commit since the last revision: > > Update InterJVMGetDropSuccessTest.java > Change BUTTON1_MASK to BUTTON1_DOWN_MASK because BUTTON1_MASK is > deprecated: > https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/event/InputEvent.html#BUTTON1_MASK test/jdk/java/awt/dnd/InterJVMGetDropSuccessTest/InterJVMGetDropSuccessTest.java line 303: > 301: boolean success2 = false; > 302: synchronized (Util.SYNC_LOCK) { > 303: robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK); I suppose this would work but the code is hard to read. 1. You are synchronizing on SYNC_LOCK on multiple places: sometimes in the listener method and sometimes around the listener methods. It is hard to make sure that the fields are properly guarded. 2. The SYNC_LOCK was originally needed just to call wait/notify, you are using it for more than that now, which is less transparent. 3. Finally the access to the listener's field is already partially guarded as method calls from the drag happen on the AWT event queue. It would be easier to understand if calls to the methods which originates from main would also go through the event queue. That is, after all, the most common approach for the java UI code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16396#discussion_r1394702525
