Mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neeme Praks <ne...@apache.org>
Subject Wicket + java->javascript compiler?
Date Tue, 03 Apr 2007 16:25:33 GMT
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/wicket-user@lists.sourceforge.net/msg17601.html


Mime
View raw message