Blogging Pubbitch

That's better.

Over the Christmas holidays I've been chipping away at something that I've wanted to do for a long time: rework the IE driver to sit more completely on the C++ underpinnings, removing the JNI layer and replacing it with JNA. As part of the process, I've finally started writing more code for the .Net bindings too.

There's still a chunk of work that needs doing, and I'm taking the time to also make some changes to bring the code more into line with the Google C++ coding style, but it's been a fun little project to work on during the break. It also means that the long-rumoured Python bindings should be a doddle to put together too.

Hurrah!

The work is in the "dotnet_bindings" branch of the webdriver project on Google Code, if you'd like to have a look.

Of course, I'm now in a bit of a quandary. Removing the complexity of JNI is a Good Thing, in and of itself, so continuing with the work of adding JNA makes a lot of sense. The problem is: do we write a native binding for each and every language and browser (so L*B different drivers) or do we write some minimal wrappers, allowing the use of idiomatic language constructs, which call down to an underlying Java driver?

I think that one of the problems that I'm considering is the resistance of some people towards "Java" as a concept. The old myths about it being slow, consuming too much memory or not being created by a sanctioned vendor are issues that need to be considered.

Given the fact that if you're using WebDriver you're about to bear the cost of starting a browser and bouncing around all over the network even the startup cost of the JVM is negligible. Once the JVM is up and running, it runs extremely well. More importantly, it's likely that our tests are IO-bound rather than CPU-bound, so even if our test language of choice was something tediously slow it's unlikely that it would be the bottleneck in our testing.

So, "pffft" say I to the argument that Java's too slow. It's a mature response, I think we can all agree.

The argument about consuming too much memory is an interesting one, but again it's not something that I'm buying into. Modern machines have gigabytes of RAM, and (again) browsers are probably going to consume more memory than the test itself, particularly if a long-running browser instance is used. So, unless we're working back on 1998-era machines, the memory argument is a bit of a non-starter too.

Finally, there's the argument that Java doesn't come from a sanctioned vendor. Normally, this attitude is most common in Microsoft shops, but I've heard the same thing from escapees from Java, and I've worked on projects that were tied to a 1.4 release of the JDK because key parts of the infrastructure couldn't be updated to use Java 5 (sounds unlikely, but it's true) This is unfortunate, because WebDriver requires Java 5 or above.

Now, there are three ways of dealing with this last argument: to ignore it, to hide Java, or to write a native binding. The first of these doesn't really appeal to me, because if it's a problem that needs addressing, we really should address it directly. The second of these is pretty acceptable to me, but I've worked in places where that sort of trick would be frowned upon (and by "frowned upon", I mean "have the technology thrown out of the project") The problem gets harder to deal with in the hypothetical case where another library does the same thing. I'd imagine that attempting to load multiple JVMs, particularly different versions, would lead to all sorts of fun and games.

It's probable that I've overlooked something obvious, or that my worries are as detached from reality as something not terribly real, such as a unicorn selling delicious bacon burgers. I suppose it would be possible to do what the existing Selenium RC implementations do (start an external process), but that's a little unwieldy, even if it is properly hidden away. If people want to weigh in with an opinion, please do so either on your blog, in the comments here or on the webdriver group. I'd love to hear some other thoughts about the best way to handle this sort of thing.

For now, the best way forward looks like writing separate bindings for the key languages, which are Java, C#, Ruby and Python in my view. On the down side, this means that in order to wander freely across the codebase, you need to know a heck of a lot of languages. On the plus side, this approach means that it's easy for anyone who has knowledge of any of the various languages to come and join the project, and just focus on the bit that they'd want to use, or which they care about.

Come! Join us...! Join us...! :)