First of all, we already have examples of both: Sun JDK 1.5 is a highly evolved JIT, and GCJ 3 is a highly evolved WAT. In benchmarks, they produce code that runs at comparable speeds. The speed advantage GCJ gains by not having to compile at runtime (and by able to apply time-intensive compilation optimizations), it loses by not having runtime/profiling information available. Profiling is a pain, it's unlikely most GCJ developers will ever use it.
That said, there are other pros and cons.
WAT-compiled code requires a smaller runtime system, their programs load faster, they probably use less memory at runtime, and they run at a (more) consistent speed. This makes WATs especially well-suited for PDAs and other mobile devices, which may not have an extra few dozen megabytes to spare for a full JIT-based Java system.
WATs also allow tighter integration with non-Java code: GCJ produces object code fully compatible with C++. For this reason, GCJ's CNI interface is really fast, while JNI can never be. If you wish to link together a lot of Java and non-Java code as an integrated unit --- for example, you wish to do Numerical Analysis using the standard LAPACK libraries, or you wish to build a Swing front-end to an existing C/C++ program --- CNI will always be more satisfactory.
In general, WATs are very satisfactory for systems programming and standard applications programming.
GCJ begins to fall short where you wish to use Java's dynamic loading/linking capabilities. Classes must be loaded dynamically, garbage collected when they're no longer used, and integrated with the existing code. They must be bytecode-verified and sandboxed. I'm sure that someone who's really clever could make this all work under GCJ. But it essentially requires the "glueing together" of two very distinct compilation models --- the static and the dynamic. And it is unsatisfactory for many applications if the dynamically loaded code behaves differently --- for example, runs 3-5X slower because it's being interpreted. A fully dynamic fully JIT-based system seems simpler and more likely to work well for these applications.
Finally, as of last summer, GCJ was not "drop-in" compatible with Sun's javac. You cannot just take an Ant script and replace "javac" with "gcj" and have it all work. With GCJ, you pretty much want to use the GNU build tools. And if you wish to dynamically load any classes, that requires additional tinkering. These are all issues that, in practice, diminish GCJ's full Java compatibility.
In conclusion, I think there's room/place for both approaches. I'd like to see Harmony develop a first-class JIT system, since GCJ has already done a good job on the WAT approach.
