richard.bair at oracle.com
Wed Feb 22 12:23:30 PST 2012
> On 2/22/2012 8:12 PM, Richard Bair wrote:
>> 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.
> Are we sure we'll never ever want to have an implementation of the FXRobot class that would generate real, native input events? (i.e. be based on Glass' Robot implementation?)
I'm not even sure how many robots we have! I guess there is AWT, Glass, and FXRobot?
>> Shura, do you use FXRobot at all?
>> 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?
> ...but if SQE agrees (and AFAIK they currently use AWT Robot only), then I'd say that removing it all together seems like the best solution for now. We can always add it back if we need to.
If nobody is using FXRobot I'm all in favor of just removing it.
More information about the openjfx-dev