Ed Burns's Blog

Compilllers are Helpful

When working to revive Webclient as a means to enable one to write automated tests for Ajax Applications, I ended up fixing some thread safety assertions that were failing in native code. Part of this involved slightly recrafting the design of the native/Java DOM bridge, originally written over seven years ago by Igor Kushnirsky. Igor's original design had lots of public native methods. My problem was that I needed these methods to have their native code executed on a particular thread. However, the DOM methods can be called from any old thread in the application. Webclient already does this with an internal NativeEventThread class. All webclient methods that end up in native code happen on that thread. Basically, I had to go through the Java DOM code and turn this:

public native Element getElementById(String elementId);

into this:

public Element getElementById(String elementId) {
  // Make this happen on the NativeEventThread.
  return nativeGetElementById(elementId);
}
native Element nativeGetElementById(String elementId);

Of course, I would have to modify the function names in the native C++ source files as well.

In case you were wondering, I did consider these solutions but rejected them.

Use Javier Pedemonte's Java XPCOM bridge

I plan to completely rewrite the mozilla layer of webclient and dom to use this most excellent software after I get the 2.0 release done. I don't have time for that extensive rewrite now.

Use aspect oriented programming techniques

Sure, I could do this, but I don't want to introduce another dependency on another technology.

That said, I wrote some xemacs macros as I went along and it only took a couple hours of manual editing. While doing it, I re-compiled all along the way. Naturally, the compiler caught some things, which I easily fixed, as I went along.

This got me thinking. Say this code was written entirely in a scripting language. If so, this sort of "complicated, human-assisted global search and replace" change (I won't call it refactoring since this particular process was so specific to JNI) would be really error prone and hard to debug. The absence of a type checking compiler would really make this sort of change hard.

I assert that this sort of change is happens all the time in the maintenance phase of a large software project. I assert that the person making the change is seldom the same person who wrote the code originally. Given these assertions, I predict much woe for the maintenance programmer who has to do such a change on a scripting language based project. I continue to urge caution for those listening to scripting zealots when they consider moving more of their projects to scripting languages.

Comments

• I agree that strict typing and a good compiler are a good thing for very large apps, but if the original was written in Ruby, you wouldn't need to change any client code - you'd 're-open' the original class and replace the getElementById method with one that ensured everything was on the right thread.

  Javascript/Actionscript can do similar tricks, but most JS/AS environments don't support multi-threading either :-)

  Also, a good set of unit tests should verify that all is well, regardless of the language used.

  Posted by: goron on March 12, 2007 at 11:16 AM

• Hi Ed,

  > design of the native/Java DOM bridge, originally written over seven years ago by Igor Kushnirsky.

  I was not involved with the Java DOM bridge. It was Akhil Arora's project.

  
  Thanks,
  Igor Kushnirskiy

  Posted by: idk on March 31, 2007 at 08:09 PM

This work is licensed under a Creative Commons License.