[I'm going to copy over the blog entries I made on jroller.com before blogs.sun.com came into being. This is the first of them.]
My username on this site is "robogeek", and I want to explain how this name came into being. Basically, I co-developed the java.awt.Robot class getting it put into JDK 1.2.2 (as sun.awt.Robot) and later into 1.3 as java.awt.Robot. The following is the story of how that came to be.
In the summer of 1998 I was hired, on contract, to work on test suites for AWT (at Sun). In a previous job I'd worked for Mainsoft developing their cross platform GUI toolkit, and that experience clinched getting this job. In any case, the first thing the manager said to me was "You're going to be developing test suites, so if you want to avoid being in test execution you had better make them automated test suites". Hmmm, I thought, as a developer (at that point I had 8 yrs of software developer experience in various silicon valley companies), not a tester, I certainly didn't want to be in a job where test execution was a major part, so I focussed on the question of automating the test execution.
A little bit of research showed me a few things. First, there weren't any suitable commercial tools because we (Sun's Java team) were cross-platform (Windows and Solaris only at that time, today it's a much bigger execution matrix), but none of the GUI automation tools were cross-platform in the right way. That's largely still true, as I've written here: TestingGUIApplications
The next thing was that Java Star (a Sun product) was completely ill-suited to testing AWT. This was a Sun product, and did it's GUI automation via sending events into the event queue. That worked okay (in a sense) for Swing applications, but not for AWT, since the AWT components did not react to those events. They would only react to events coming in from the operating system. Further, since the events Java Star synthesized did not go through the native level of AWT, we could not say that we had tested AWT at all. The most interesting part of AWT is, after all, the code that handles the interface with the native windowing system. For our team, which is in charge of validating the Java that the rest of y'all see, to say that we had tested AWT, any GUI automation would have to synthesize events that arrive in the same manner as events from the user playing with their keyboard and mouse.
My next stage (oh, alongside this I was developing several test suites) of research was how to synthesize events. Being most comfortable with X11 I developed that side first, intending to take this to the AWT developers for help with the Win32 side. I called this module "NativeEvent" and after finding the X11 XTEST extension, learned how to write JNI code and wrote up a module.
Unknown to me the AWT developers were planning a similar module. When it came time to show them my NativeEvent module, they were about to come to me and propose a Robot class which would help test automation occur. Great minds think alike, don't they? In any case, that led to a collaboration with Robi Khan (then with the AWT development team) to create Robot, Robi concentrating on Win32 and me concentrating on Solaris.
An early version of Robot existed as a private class in 1.2.2 (sun.awt.Robot or some such) and we were able to use it for some test automation. I was, and am still, glad to see the team able to get out of doing some of the test execution by hand.
We discovered a major problem between the 1.2.2 and 1.3 release (where Robot first was public). Namely, on X11 the Xlib is not thread-safe, generally. Some Xlib's are thread-safe, but we could not depend on that, and certainly Solaris's Xlib was not thread safe. It was pretty easy to get Java to crash through using Robot.
The problem was, if you had one Java thread making a Robot call at the same time another thread was in another call which resulted in entering Xlib, well, you have two threads in Xlib at the same time. Not being thread-safe, the resulting crashes were to be expected.
Another aspect of this problem was deadlocks during drag & drop operations. To avoid multiple threads accessing Xlib, the AWT team use(d) AWT_LOCK and AWT_UNLOCK macros in the AWT/Motif source. This acted the same as the synchronized keyword at the Java level, causing a thread to block if another thread held AWT_LOCK. The first cut simple solution to the Robot crash was to use AWT_LOCK/UNLOCK. However, the D&D subsystem of that time would hold AWT_LOCK for long periods. This meant that if the test application called Robot methods during a D&D operation, then the Robot call would get blocked waiting for AWT_LOCK. Since whatever method is making the D&D calls is the one driving the test application, the test application was effectively blocked. Even though this was against the design rule for AWT_LOCK (which wasn't supposed to be held for long periods of time) the AWT team could not change this, since it would have been too expensive and risky to redesign D&D.
A number of experiments were tried ... for example to have a second DISPLAY connection for Robot's use. We wanted to keep the X11 Robot in the same address space, but in the end we could not. Every experiment led to either crashes or deadlocks. In the end we had to create a child Robot helper program, and it's that helper program which makes the XTEST calls.
In any case, after all that Robot was ready and unleashed on the world. As a result there have been several GUI automation tools be developed for java, which would not have existed had Robot not been there.
See TestingGUIApplications for more information.
- David Herron
(2004-07-30 13:31:55.0) Permalink
