On 09/09/2014 03:28 PM, Sergey Bylokhov wrote:
On 09.09.2014 15:15, Anthony Petrov wrote:
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.
I suggest to take this as a backup plan if something will go wrong. We
have a good coverage and we have enough time for testing.
BTW ExtendedRobot already has this waitForIdle() re-implementation
with realSync(), and it seems working not bad in the new[ish] tests
where it is substituted instead of original Robot.
We certainly intend to use it in future.
It depends, however, on some explicit or implicit delay together with
native synchronization. I mean, basic method is waitForIdle(delay) and
convenience method waitForIdle() with a default delay.
And note that many tests do not instantiate Robot but use realSync.
Therefore we still will have _another_ non-trivial waitForIdle
in ExtendedRobot or reimplement AND add a new public method to Robot.
And in addition we still need a static method for those who don't
instantiate Robot at all.
Cheers,
-yan
--
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
