“To be as small and as efficient as possible”!? I admire GWT team for their excellent 100k ~ 200k final *.js files with very good performance.
I am just a lazy developer, lazy to learn new APIs for some same functions. For example, Swing and SWT are similar GUI toolkit. And using SWT can do all the things that Swing can do and vice versa. I would be lazy to learn one of them only and not to learn the other. And I prefer to SWT. And as now I am familiar with SWT, and if all things done by using GWT can be done by using SWT, I would be lazy not to learn the new GWT APIs but use my familiar SWT. So this lazy programmer will use Java2Script and its Java2Script SWT library.
GWT’s compiling procedure is somewhat similar to the procedure of compiling C sources into an executable file. In C compiling, C source is first compiled into an *.obj.? And then comes a linker, which will link *.obj with other *.lib files into an *.exe. In the linking procedure, not all method calls in those *.lib are linked into *.exe file. Only those which are used in the *.obj will be kept. Others may be discarded so the final *.exe is small and efficient. In order to find out which methods must be kept in linking, some recursive searching algorithm may be required.
And I admire GWT team for their excellent 100k ~ 200k final *.js files with very good performance.
But GWT, as the above compiling process described, may have its difficulties in supporting Java refection and dynamical class loading. But Java2Script already has its ClassLoader and is loading classes lazily. And it also has its early Java reflection implementation on JUnit tests (Reusing JUnit tests directly). But the way, GWT APIs and Java2Script SWT APIs is far different for comparison.
Maybe GWT would be kind to support Java reflection and dynamic class loading, if more developers vote for such features.
Pingback: Inside Java2Script » Blog Archive » Performance Matters or Not