Skip to main content

Compilllers are Helpful

Posted by edburns on March 12, 2007 at 9:11 AM PDT

When working to revive href="">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.

Technorati Tags:

Related Topics >>