wat kind of java code that you now write in/with wicket would you like to compile to js?? What kind of ajax things are we talking about?
On 4/3/07, Neeme Praks <[EMAIL PROTECTED]> wrote:
Hi all, I'm evaluating and researching around the net for the best approach to build AJAX and non-AJAX web/wap applications by reusing as much code as possible. I'm almost convinced that using Wicket for non-AJAX applications is the best option currently available (even if I have to add WML support myself). However, the AJAX part in Wicket is still not on the level that I would like it to be. From the brief look I had, it depends too much on various semi-static, semi-hard-coded "scriptlets" and requires me to put most of my logic running in the server with small javascript callbacks from client (this assumes that I want to write as much logic as possible in java and use all the benefits that come with that). Or, I can have most of my logic in client-side, but then I have to write all that client-side logic in quite error-prone JavaScript. Consequently, this option will mean that if I want to have an application that also handles non-AJAX clients gracefully, I will need to maintain same logic in java (server-side, for non-AJAX clients) and JavaScript (client-side, for AJAX-capable clients). As you might guess, I would like to have something that would allow me to write code once and then, depending on the client, the code will be either run "as-is" (server-side) or converted into JavaScript (client-side). In order to achieve this, we have mainly two compiler options: * GWT, http://code.google.com/webtoolkit/ - Google has now open-sourced their compiler, but I haven't looked deeper. License: Apache 2.0 * java2script, http://j2s.sourceforge.net/ - independent attempt to create a java-to-javascript compiler, extending Eclipse JDT, using abstract-syntax-tree (AST) to generate the javascript. License: Eclipse Public License 1.0 License-wise I think both are OK. Below I've made an initial analysis of these two projects, mainly from the point-of-view of how easy it would be to integrate one of them with Wicket. For evaluation, I came up with a list of questions: * what java features are available in javascript produced by particular compiler? - notable are only the features that are actually possible to achieve. JavaScript, by nature, does not support some java features, such as: some/most intrinsic types, multithreading+synchronization and finalization. * what standard class libraries are available? * how to decouple compiler from the main distro? * how is the javascript produced and how easy is it to integrate it with Wicket? And now the details. *GWT* (http://code.google.com/webtoolkit/) DISCLAIMER: I personally haven't looked too deep into GWT so someone with more experience might want to comment on these notes. Anyway, to the list: * java features - reflection is not supported, and, as a result, tracktraces are also not supported. Assertions are not supported. source: http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.Fundamentals.JavaToJavaScriptCompiler.LanguageSupport.html * standard class libraries - as far as I understood, most of java.lang and java.util. Not all classes are implemented from those packages. source: http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.Fundamentals.JavaToJavaScriptCompiler.JavaRuntimeSupport.html * decoupling compiler - I have no idea what it would take to achieve that. * how is the javascript produced? - it is stated on GWT language support page that "for maximum efficiency, GWT compiles your Java source into a monolithic script" - this sounds like something that is not easy to reuse outside GWT context. I have also tried to dig around in the source code of GWT generated web applications - it looks quite ugly. *java2script* (http://j2s.sourceforge.net/) First thing you will notice about the project that it is a one-man show and the usage of English language is a bit strange. But who cares, nobody is perfect and as long as the code is good and documentation understandable, I don't care too much about that. Some background information: the project tries to achieve recompiling existing SWT applications into AJAX applications with minimal code changes (SWT stands for Standard Widget Toolkit, http://www.eclipse.org/swt/). In a sense, this goal is similar to my goal with Wicket. Anyway, to the list: * java features - basically all features are implemented that are possible with JavaScript limitations. This means that reflection is supported, not sure about stacktraces, but it seems to be also supported. source: http://j2s.sourceforge.net/document.html, bottom of page * standard class libraries - java.io, java.lang, java.lang.reflect, java.util. Details need to be investigated. I guess java.io.File is not implemented ;-) source: http://j2s.sourceforge.net/document.html, bottom of page * decoupling compiler - current implementation only runs inside Eclipse, but it should be fairly easy to take it out from there, Eclipse JDT Core supports a headless mode. Some discussion about this is here: http://blog.interface21.com/main/2007/01/21/java-to-javascript-compilation-with-ajax-and-spring-integration/ * how is the javascript produced? - as java2script tries to follow java conventions as much as possible, JavaScript is also generated nicely, one .js file per .java file. The tricky part is to get the classloading order right - to ensure that <script> tags that load .js files appear in the right order. The author recommends to do this manually, but I trust machines more with this kind of task and it shouldn't be too difficult, just a matter of investing some time in it. To sum up, java2script feels somewhat more suited for Wicket needs, when compared with GWT. GWT tries to be toolkit for building _web_ applications and the compiler is somewhat tied to that assumption. Also, the remoting method of GWT is most probably tied to the compiler - you need to extend a GWT special class in order to be serializable (haven't looked at the source, but got that impression from the documentation). java2script, on the other hand is not really about _web_ applications, but more about how to turn java code into working javascript with minimal changes. In this sense, I think java2script is a good match for Wicket. In the end, GWT is not designed to be extended; java2script author on the other hand has even written a short guide on extending the core, available at http://j2s.sourceforge.net/articles/tutorial-extended-compiler.html. I welcome all discussion on the topic and I will also try to put together some sort of proof-of-concept, if nobody will beat me to it. Rgds, Neeme P.S. there was some discussion on similar topic before, but then GWT compiler was out of question as closed-source technology: http://www.mail-archive.com/[email protected]/msg17601.html
