RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot [v6]
Sergey Bylokhov
serb at openjdk.org
Wed Sep 17 01:14:40 UTC 2025
On Mon, 15 Sep 2025 19:34:14 GMT, Phil Race <prr at openjdk.org> wrote:
>> src/java.desktop/share/classes/java/awt/Robot.java line 849:
>>
>>> 847: public synchronized void waitForIdle(int delayValue) {
>>> 848: waitForIdle();
>>> 849: delay(delayValue);
>>
>> 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?
>
>> 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.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26969#discussion_r2353971350
More information about the client-libs-dev
mailing list