<AWT Dev> Review Request for 8056911: Remove internal API usage from ExtendedRobot class

[Anthony Petrov]

Hi Sergey,

I've indicated earlier on this mailing list that calling realSync() from 
waitForIdle() unconditionally is too risky. See:

http://mail.openjdk.java.net/pipermail/awt-dev/2014-August/008402.html

However, we might consider introducing the following method instead:

Robot.waitForIdle(boolean nativeSync)

and the current waitForIdle() would simply call waitForIdle(false).
This would be safe enough and elegant enough as no new method names 
would have to be introduced.

--
best regards,
Anthony

On 9/9/2014 3:07 PM, Sergey Bylokhov wrote:
> On 09.09.2014 14:40, Anthony Petrov wrote:
>> Hi Dmitriy,
>>
>> Robot.sync() could also sound confusing if one remembers there's
>> Toolkit.sync() already.
>>
>> Why not name it waitForNativeIdle(), analogous to the already existing
>> Robot.waitForIdle()? The methods perform similar actions, the only
>> difference is the event queue they perform these actions on. If we
>> choose this name, then the javadoc could be copied almost verbatim
>> from the waitForIdle() method with a few additional "native" words
>> inserted here and there.
> The simpler way to fix it is to reimplement Robot.waitForIdle() on top
> of SunToolkit.realsync() and extends of documentation of this method.
> Because most of the time waitForIdle/autoWaitForIdle are used after some
> key/mouse manipulation, I guess it is too verbose to write this:
> Robot.waitForNativeIdle()
> Robot.waitForIdle()
>
>> In general, I'm fine with this approach of resolving this issue.
>>
>> --
>> best regards,
>> Anthony
>>
>> On 9/4/2014 3:25 PM, Dmitriy Ermashov wrote:
>>> Ok, I've prepared an updated version of patch
>>> http://cr.openjdk.java.net/~dermashov/8056911/webrev.01/
>>> Please, review new version.
>>>
>>> I've moved a method implementation to Robot class. We've decided that
>>> adding new method to Toolkit class with similar to sync() method
>>> functionality but with a different name could hardly look elegant, and
>>> besides, new solution could be less conspicuous.
>>>
>>> Thanks,
>>> Dima
>>>
>>> On 09/01/2014 04:49 PM, Yuri Nesterenko wrote:
>>>> Phil,
>>>>
>>>> perhaps javadoc should be changed, yes.
>>>> It is the first public spec for Dmitriy.
>>>>
>>>> As to the narrow purpose, are you serious?
>>>> We have nothing to replace this invention. Original idea
>>>> was to replace Toolkit.sync() with realSync() but
>>>> after JDK-6252005 Denis left us, there was no resources
>>>> and no hard demand to avoid the internal API.
>>>> Now it is here. Demand is here, not resources. Are you going
>>>> to design and implement something new to help SQE?
>>>>
>>>> -yan
>>>>
>>>> On 08/29/2014 07:33 PM, Phil Race wrote:
>>>>> So you are proposing adding a new *public* API for this narrow
>>>>> purpose.
>>>>> And it calls out a whole bunch of internal classes in its apI doc !?!
>>>>>
>>>>> 2642      * <p> The method calls {@link
>>>>> sun.awt.SunToolkit#realSync} to
>>>>> 2643      * sync with native event queue
>>>>>
>>>>> @throws  sun.awt.SunToolkit.IllegalThreadException if called on the
>>>>> AWT event
>>>>> 2646      *          dispatching thread
>>>>> 2647      * @throws  sun.awt.SunToolkit.OperationTimedOut if the
>>>>> 2648      *          {@link sun.awt.SunToolkit.OperationTimedOut}
>>>>> exception occurs in
>>>>> 2649      *          {@link sun.awt.SunToolkit#realSync}
>>>>> 2650      * @throws  sun.awt.SunToolkit.InfiniteLoop if the
>>>>> 2651      *          {@link sun.awt.SunToolkit.InfiniteLoop}
>>>>> exception occurs in
>>>>> 2652      *          {@link sun.awt.SunToolkit#realSync}
>>>>> 2653      * @throws  ClassCastException if default toolkit is not
>>>>> SunToolkit
>>>>>
>>>>>
>>>>> I am also not sure how confident I am that the statement
>>>>>
>>>>> his method guarantees that after
>>>>> 2637      * return no additional Java events will be generated, unless
>>>>> 2638      * cause by user.
>>>>>
>>>>> is actually guaranteed.
>>>>>
>>>>>
>>>>> My initial reaction to such a proposal is instead look hard for a
>>>>> better
>>>>> way even if it means re-writing all the tests.
>>>>> There's also the proposed 'jdk.*' name space that can be considered
>>>>> but re-writing the tests would be better.
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 8/29/14 8:11 AM, Dmitriy Ermashov wrote:
>>>>>> Hi awt team,
>>>>>>
>>>>>> Please review a fix for 8056911, remove internal API usage from
>>>>>> ExtendedRobot class.
>>>>>> We have to throw out all calls of sun.* packages from tests
>>>>>> because of
>>>>>> incompatibility with Jigsaw project.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dermashov/8056911/webrev.00/
>>>>>>
>>>>>> The CCC request will take place after the review process will be
>>>>>> completed.
>>>>>>
>>>>>> Thanks,
>>>>>> Dima
>>>>>
>>>>
>>>
>
>