RoboGeek

Can Sun and Microsoft compete/cooperate

[This is the second of the copied-over postings from my jroller.com weblog]

There's ruminations running about over whether we can compete and cooperate at the same time.

For example, see here http://news.com.com/2100-7343_3-5207581.html?tag=nefd.lede

Obviously there's been a lot of acrimony between our companies (I work for Sun) over a long time. Just as obviously, Sun has a history of cooperating with their competitors over areas where it makes sense to cooperate. This apparent contradiction has a long history in business in general, and around 10-15 years ago I remember the word "Coopetition" being bandied about to describe this state.

Coopetition being the state where two or more companies cooperate on some things and compete on others.

In computing the obvious example are the standards committees. Computer and software companies have to agree to cooperate in areas covered by the standards. Without the JPEG standard, for example, would the World Wide Web be so easily able to embed pictures in text on web pages? No, because if every computer or software maker had their own proprietary image format then it would be a nightmare for end-users to figure out how to view each picture. The nonchalant use of images on web pages we have today, that makes the web look so nice, would just not be done.

An example specific to Sun is the IBM/Java connection. IBM probably has more people working on Java than Sun does, but then IBM has a much worse platform proliferation story than does Sun and IBM has to have more people working on Java because of the huge number of hardware platforms they saddled themselves with. In any case, IBM and Sun obviously compete in many areas (hardware, software, etc) and even compete with each other over Java. But we also cooperate with each other over Java, because obviously it's good for the Java market for us to cooperate on it.

In any case, all this is way of an example why I think that Sun and Microsoft can cooperate. Amongst the people I work with we, in the Java/J2SE team, have a lot of knowledge about Microsoft's operating system and other software products they make. We have to, because Microsoft hasn't been cooperating with us on the production of Java, which leaves it to us, Sun, to make the Windows version of Java. The Microsoft/Sun/Java deal could have happened differently if, years ago, Microsoft had chosen to play correctly with the Java market. There might not have been need for the lawsuits and the rest, had Microsoft chosen to play nice. They didn't, and we learned a lot along the way.

Sun has a clear business need to interoperate better with Microsoft's infrastructure. But that doesn't mean we need to sell their software. Just having documentation of their protocols (which I understand is in the core of the agreement) is enough, as we have a lot of smart people hanging out in this company. Why would we do this? Well, obviously, any corporation to which Sun wants to sell server hardware is likely going to have some Microsoft equipment hanging around as well. Obviously, then, it'll be easier for Sun to sell that hardware if we can show better interoperability with that Microsoft equipment.

Have we sold our soul to the devil?

Well, only time will tell really. A couple years ago I predicted that Scott McNeally would have another M-M-M-xxx moment, this time over Microsoft. If you recall, in the 80's and early 90's Sun was a pre-eminent workstation maker (servers were a sideline intended primarily to support the workstations). The GUI environment was important to Sun, and Sun had chosen the NeWS (a previous Gosling project), and later xnews and open look, environments for their workstations. But the rest of the Unix industry joined together to make OSF (Open Software Foundation) and the Motif/CDE environment. Some wags claimed OSF meant Oppose Sun Forever. In any case, Scott used to rag on Motif just as strongly as he ever ragged on Microsoft, and supposedly we'd support Motif over somebodies dead body. Seems that kind of hyperbole just never works, because the Sun marketing staff had to trot Scott up onto a stage so he could stumble over the word Motif in saying that Sun would support the CDE environment, ditch its Open Look environment, etc.

What I predicted a couple years ago was that eventually we'd have to trot Scott up on a stage to say nice things about Microsoft and whatnot. Well, that finally came to being. Just like Sun put the anti-Motif thing behind it, so will we put the anti-Microsoft thing behind us. We're all adults here, so why can't we do this?

The birth of Robot

[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