Alexandre (Shura) Iline alexandre.iline at oracle.com
Wed Feb 22 16:02:21 PST 2012

On 2/22/12 8:12 PM, Richard Bair wrote:
> Hi all,
> I have a few issues logged against FXRobot (particularly, to clean up the TODOs) and so I took a few moments this morning to look it over. The code is in javafx-ui-common in the com.sun.javafx.robot package.
> First question, at present there is an FXRobot base class and a factory and a BasicFXRobot implementation. Is this structure still relevant? I have my hunch that this is carry over from back in the 1.0 days when we had a separate JavaFX Mobile implementation, whereas now we are consolidated on a single implementation and it should no longer be needed to have this separation. I prototyped merging the BasicFXRobot implementation into the FXRobot class, making FXRobot final, and removing the factory. The runtime builds fine.
> Shura, do you use FXRobot at all?

No, we do not.

We are looking on using glass robot for some cases right now because of 
some image grabbing issues but that is it. Glass robot is not a part of 
public API, so it should not be a problem.

> Does anybody really use FXRobot right now? I don't think any of the unit tests use it (and in fact, there have been utilities added to the unit tests to generate fake key events and so forth, so I'm pretty sure FXRobot is not in use here).
> There are also some odd dependencies -- accessors -- in KeyEvent for example such that KeyEvent calls into FXRobotHelper with a static initializer and so forth. What is that all about?
> My hunch is that either (a) FXRobot isn't really used and therefore we can just chuck it or, (b) SQE is using it, but it could be simplified and the funny back references from KeyEvent etc can probably be removed (although since I don't know why they are there in the first place I can easily be off base here).
> Shura, others, can you guys help shed some light here?

Definitely (a).


> Thanks
> Richard

More information about the openjfx-dev mailing list