Ed Burns's Blog

March 2007 Archives

Pre-JCP-filed draft for JavaServer Faces 2.0 JSR

It's about time we get moving on JSF 2.0, so Sun's JSF team decided to go public with a pre-JCP-filing of the JSR for JavaServer Faces 2.0. The draft of the document at <https://javaserverfaces-spec-public.dev.java.net/proposals/JSF-2_0-draft.html> has been through several rounds of Sun internal review and also was reviewed by the JSF 1.2 Expert Group. Please review the draft and post comments here on this blog.

If you want to go even deeper into shaping JSF 2.0 and the JSR submission, you can view and edit the wiki for a JSF 2.0 Requirements Scratchpad document. When the JSR gets rolling, the requirements in that document will be turned into issues in the JavaServer Faces Specification Issue Tracker.

Finally, I'd like to take this opportunity to extend an invitation to several individuals outside of the JSF community to join us in developing the next version of the Java standard web application framework. Specifically, I call upon Howard Lewis-Ship, Geert Bevin, Eelco Hillenius, and Tim Fennell to consider Joining the JCP so they can join the Expert Group when it forms. Of course, there are many other folks whose expertise would be appreciated on the Expert Group, but Howard, Geert, Eelco and Tim come to mind because each of them has their own web framework outside of JSF.

Please let us know what you think about starting JSF 2.0!

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.

This work is licensed under a Creative Commons License.