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 <neeme@apache.org> 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/wicket-user@lists.sourceforge.net/msg17601.html
>
>
|