Symphonious

A fair while back I commented on a job opening at Microsoft, noting that my blog would probably work against me in that particular case due to it being so critical of Microsoft.  Robert Scoble noted that Microsoft don’t want to hire evangelists that just drink the company Kool-aid and have no credibility.  He’s right of course but slightly missed my original reasoning.  It’s not so much that I’ve made some negative comments about Microsoft - more that I pretty much have never said anything positive about Microsoft on my blog.  I was supportive in my "Missing The Point" entry about Microsoft’s new interoperability initiative and did defend beta releases which were relevant to Microsoft at the time, but that’s about it.  See for yourself.

Not that I intend to be anti-microsoft, I don’t play around with new Microsoft technology all that often (and my experiments with the latest SQL Server betas were less than successful - though that’s probably just my lack of knowledge).  I’ve taken to watching Microsoft more lately - that’s why I subscribed to Robert Scoble’s blog in the first place and I’m slowly building the list of Microsoft related news sources I scan for information.  Still, I’m not seeing anything that particularly excites me. Much of that is because Microsoft has made such a mess of the Longhorn release - an event that just happens to be unfolding over the time period that I’ve been watching closely.  I’m sure Longhorn will be a great release for any number of reasons, but at the moment the public perception that I’m getting at least is of a child lost in the woods.  I’m sure they’ve got plenty of smart people to straighten that out though.

I’m a developer so .Net should be of interest to me, but I just don’t see anything hugely beneficial in it (.Net and Java are happily pinching ideas from each other so they remain roughly on par and Java is significantly more popular at the moment, plus I already know it well).  Worse than that though, Visual Studio.Net has proven to be the single most infuriating experience I’ve ever had with technology.  Sure I didn’t know what I was doing but I’ve been more clueless about many other things and not been driven that insane by them.

I’m just not passionate about Microsoft technologies at the moment and that would make me a bad evangelist.  The comments I’ve made on my blog just reflect that.  Having said that, if someone wants to buy me a tablet PC, at the very least I’ll be excited about the money I’ll make hocking it on eBay…

(Okay, that was a little cheeky…)

PS: The delay in revisiting this topic was caused by NetNewsWire enforcing a boycott of Scoble’s blog - for some reason it just stopped downloading updates and I didn’t notice.  How do you not notice half a million entries a day going missing?

Gianugo Rabellino has been playing with unit testing in Swing - an area that I’ve spent a lot of time complaining about in the past.  In his particular case he’s trying to send key events to Swing components programmatically so that his JUnit tests can run automatically.  As Gianugo discovered you can’t just create a KeyEvent and send it to Component.dispatchEvent() because it gets rerouted to the focus manager.

Gianugo’s solution was to display the component on screen in a JFrame and make sure it has focus.  However, we can go one better - we can simulate the component having focus.

The interactions between Component.dispatchEvent() and the FocusManager are somewhat odd.  Component.dispatchEvent() sends the request to the FocusManager without actually checking if it has focus or not.  The FocusManager picks the component that has focus and sends the event to it’s Component.dispatchEvent() method.  It’s an infinite loop except that the Swing team so helpfully created a package private (read: totally hidden and inaccessible) variable in KeyEvent called focusManagerIsDispatching which tells the Component.dispatchEvent() method not to redirect the event over to the FocusManager but to actually process it like the JavaDoc suggests it will.

So, to make key strokes work with Swing components in JUnit tests we just have to set that variable to true using reflection before we pass the event into Component.dispatchEvent().  The code winds up looking something like (excusing any typos or misremembered method names - I haven’t bothered to compile this):

public void simulateKey(KeyEvent e, Component c) {
   Field f = KeyEvent.class.getField("focusManagerIsDispatching");
   f.setAccessible(true);
   f.set(e, Boolean.TRUE);
   c.dispatchEvent(e);
}

If that’s not quite right, check the code for KeyEvent and Component.dispatchEvent to make sure the variable names are right and check the JavaDoc for java.lang.reflect.Field in case I’ve misremembered a method in there somewhere.  The concept is definitely sound though.