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

[Yuri Nesterenko]

Sergey,

Dmitriy is on vacation for some 2 weeks.
You mean that (1) this second version is better and correct
but not enough;
(2) everything possible should go to the Robot, am I right?

I agree but will we have support for CCC? We can use ExtendedRobot
but cannot pass jigsaw gate (like Prince of Persia) without realSync.
Actually we can do it in two stages: an urgent first (this one)
and the slow second, with research and deliberations.

Thanks,
-yan

On 09/08/2014 03:35 PM, Sergey Bylokhov wrote:
> Hello,
> I guess that the correct way to fix this issue is to move ExtendedRobot
> functionality to the Robot class(probably with some changes), instead of
> the new API in the Toolkit class.
> But this work can require some research.
>
> On 04.09.2014 15:25, 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
>>>>
>>>
>>
>
>