On Wed, 17 Sep 2025 01:12:16 GMT, Sergey Bylokhov <[email protected]> wrote:
>>> think we should recheck whether new methods like this one need to be >>> synchronized. Some time ago, the synchronized keyword was removed from the >>> delay method because synchronization could cause the delay to last longer >>> than intended and unnecessarily block other methods. >>> >>> In this case, waitForIdle() might be in a synchronized block (but the >>> method itself is already synchronized), but do we really want to call >>> delay() while holding the lock? >> >> I expect you are referring to this fix you did about 6 years ago >> https://bugs.openjdk.org/browse/JDK-8210231 ? >> >> That bug was more about side-effects of delay but ended up removing >> synchronized. >> >>> 3. "synchronized" keyword was removed, because of this bug: "if two threads >>> call delay(1000) at around the same time then one of them will be a delay >>> for 2000ms". >> >> I'm not sure that ever affected any actual tests since Robot usage should be >> single threaded in all usual cases. >> >> I can just about see a case for removing synchronized from the >> waitForIdle(delay) method - because waitForIdle() is already synchronized >> and delay() doesn't change anything >> But for cases like type() it is important for its operation that only one >> thread be allowed. >> Just imagine the havoc if there are N robots all concurrently typing away - >> that's what is allowed by removing synchronized. > > Yes, the click operation is a different operation and it would be nice to > mark it as synchronized, but nothing is stopping the user from creating two > robots and using them in parallel, which would lead to the same chaos. Updated to make waitForIdle(int delay) not synchronized. Thanks! Will update the CSR accordingly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26969#discussion_r2377345277
