Robot (Java Platform SE 8 ) (original) (raw)

This class is used to generate native system input events for the purposes of test automation, self-running demos, and other applications where control of the mouse and keyboard is needed. The primary purpose of Robot is to facilitate automated testing of Java platform implementations.

Using the class to generate input events differs from posting events to the AWT event queue or AWT components in that the events are generated in the platform's native input queue. For example, Robot.mouseMove will actually move the mouse cursor instead of just generating mouse move events.

Note that some platforms require special privileges or extensions to access low-level input control. If the current platform configuration does not allow input control, an AWTException will be thrown when trying to construct Robot objects. For example, X-Window systems will throw the exception if the XTEST 2.2 standard extension is not supported (or not enabled) by the X server.

Applications that use Robot for purposes other than self-testing should handle these error conditions gracefully.

Platforms and desktop environments may impose restrictions or limitations on the access required to implement all functionality in the Robot class. For example:

• preventing access to the contents of any part of a desktop or Window on the desktop that is not owned by the running application.
• treating window decorations as non-owned content.
• ignoring or limiting specific requests to manipulate windows.
• ignoring or limiting specific requests for Robot generated (synthesized) events related to keyboard and mouse etc.
• requiring specific or global permissions to any access to window contents, even application owned content,or to perform even limited synthesizing of events.

The Robot API specification requires that approvals for these be granted for full operation. If they are not granted, the API will be degraded as discussed here. Relevant specific API methods may document more specific limitations and requirements. Depending on the policies of the desktop environment, the approvals mentioned above may:

• be required every time
• or persistent for the lifetime of an application,
• or persistent across multiple user desktop sessions
• be fine-grained permissions
• be associated with a specific binary application, or a class of binary applications.

When such approvals need to given interactively, it may impede the normal operation of the application until approved, and if approval is denied or not possible, or cannot be made persistent then it will degrade the functionality of this class and in turn any part of the operation of the application which is dependent on it.