Re: j2s-development] gwt groups post

[Zhou R. <jo...@sj...>]

Hi Ash,

Ash Wima wrote:
> Josson Smith wrote:
>   
>> By the way, if you have any ideas or thoughts about Java2Script,
>> Java2Script team will appreciate for your discussion on its development
>> mail-list.
>>     
>
> thx for the invitation. ill cross post so both lists can take their dig
> at me <g>. the purpose of this post is to present some random thoughts
> that i have had.
>   
Thanks for your random thoughts!
> josson,
>
> thanks again for your contribution to the thread. i appreciate your
> openness about the j2s classloader issues & ideas, and also your
> interest in understanding the motivations of the gwt compiler.
>
> i find myself routinely getting svn updates of your commits and
> monitoring your progress. there is something that is very right about
> your approach, that for me keeps gwt in check.
>
> first, let me state where i think your project is positioned (pls
> correct me where im wrong). i believe j2s is positioned b/n xml11 and
> gwt. my rationale is:
> * xml11 is server heavy and renders any awt based application to a
> browser by sending delta DOM changes over the wire in a similar fashion
> to ZK as one of its two approaches. there is work in progress to
> support both swing and swt. the point being is that if you had existing
> desktop java software that needed to be accessible via a browser, then
> this may well become the most effective solution when xml11 maturity
> improves.
> * gwt is almost completely client based, has created a new ui widget
> API that is coupled to the DOM, and does not attempt to leverage
> existing java gui APIs
>
>   
Some of my earlier thoughts about J2S: As both client(browser) and 
server are implemented in Java, developers can add annotations (or 
javaDoc tag) to leverage whether a *static* method is executed on client 
side or on server side. For example, there is a task to compare two 
files. If such a task is executed on browser side, browser will read 
(HTTP GET) two files, and make the comparison and show differences. If 
such a task is executed on server side, the server reads two files and 
make the comparison and return differences to browser and the browser 
display them.

If most of the methods are marked as being executed on server side(in 
most cases, one of two methods would be marked so), it would be just the 
same as  ZK or XML11.

Currently, J2S has not yet implemented such j2s javaDoc annotations. So, 
IMO, it is much more similar to GWT than to XML11 currently. That is to 
say, it's client based, with SWT APIs supported.
> now lets discuss ui. note, whilst im not a huge fan of the gwt widget
> API, there are the following things that i do like:
> * it is very light weight
> * it uses the clever gwt browser module strategy approach for
> addressing browser independence
> * it aims to be simple
>
>   
One or two months ago, I realized that SWT is somewhat heavy for most 
RIAs' requirement.
> to be honest, im not a big fan of swing or swt either. however, having
> said that, what i do like about j2s is that:
> 1. java developers can leverage a matured, well understood, and
> documented gui api
> 2. all widgets work out of the box (ie. no css files to hack)
> 3. it leverages an existing tools market built around swt
>
> however, let us consider how important these points are to a community
> like gwt. im sure the community will correct me where i am wrong.
>
>   
>> 1. java developers can leverage a well understood and documented gui api
>>     
>
> sure there are many old swing/swt hacks that are in this community, but
> to my surprise there are many non java folks. most of these guys would
> probably look at swing/swt code and proclaim: "what the ...".
> furthermore, there is a large advocacy for a middle ground between
> social based web apps and traditional desktop style application in a
> browser. perhaps this is where the openlazlo folks are headed. claude
> has spoken at lengths on this subject (consider searching his posts) on
> this group. therefore, should this motivation have a high priority as
> we both originally anticipated?
>
>   
>> 2. all widgets work out of the box (ie. no css files to hack)
>>     
>
> imho this is one of the most undervalued benefits of j2s. ive also
> experienced this with zk and openlazlo - things just work without
> configuration or deep knowledge. not only do u provide a near complete
> swt widget impl., but it actually renders as expected. being part of
> the client/server generation and developing apps in win3.1, win95, etc.
> it became evident what tooling was required to attract the masses. i
> think gwt (or gwt tool community) has a long road ahead and relies too
> heavily on css/graphic expertise for the masses to arrive any time
> soon.
>   
It seems that css/graphic experts would like CSS/HTML most. By the way, 
if some CSS experts would still like to use CSS in J2S SWT application, 
try to use "@j2sNative" javaDoc tag and treat SWT widget's member field 
*handle( as an HTML element handle.
>> 3. it leverages an existing tools market built around swt
>>     
>
> here again is another instance of the "minimise duplication, maximise
> leverage" prinicple. however, having enough weight behind gwt, there
> are 2 tools at present to support gui building for gwt. i use
> instantiations' windowsbuilder pro::gwt-designer edition which is
> slowly doing to gwt, what it did for swing/swt. therefore again, should
> is this motivation have a high priority as we both originally
> antipicated.
>
> finally, lets discuss some of the pain points experienced by some
> members of the gwt community.
> 1. developing applications with modules that can be dynamically linked
> and shared accross multiple modules/projects
> 2. the limited jre causes engineers to duplicate code from existing oss
> java projects when required
> 3. there is no support for reflection. gwt does support a powerful
> compile-time concept called defered binding. admittedly, most things
> can be pushed to either defered binding or the server side, but very
> occasionally you do discover the need for reflection
>
> ---
>
> i have never looked at j2s and gwt as competitors, rather ive always
> looked to complement gwt with j2s and attempt to address some the paint
> points above. i have often thought wouldn't it be cool if:
> * j2s could achieve a static (way ahead of time) compile like gcj and
> render an entire appl as a single html/js like gwt, and/or offer a
> partitioned html/js with shared objects (designers can choose with
> compiler switches)
>   
Static compiler like gcj requires more hacks over Eclipse JDT. And it 
seems that GWT already implemented its static compiler. Maybe I may 
learn something more from GWT.  Implementing static J2S compiler is just 
a time problem. And it's not in the schedule of  J2S 1.0.
> * j2s could let me statically link my library with apache commons lang
> (etc.) and render a js that i could call from gwt. hence, whenever gwt
> could not do the heavy lifting, i could turn to j2s.
>   
Coexistence of GWT and J2S may require modifications of J2SClazz 
simulator. And many problems should be studied. And coexistence of other 
AJAX toolkit libraries and J2S is a same feature request, which will be 
considered before 1.0 release. But J2S can not promise coexisting with 
all libraries very well according to maybe inconsistent technologies.
> * all of j2s's swt widgets could be synthesized into gwt, but leverage
> the low level DOM and Event abstractions rather than gwt ui widget api.
> this time focus on a more common listener interface, build drag'n'drop
> into the base and also consider component serialization and convenient
> component to component assignment
>
>   
Maybe some other projects besides J2S SWT project will do the job of 
synthesizing J2S SWT into GWT.
> ---
>
> in your blog u felt that this thread became x v's y. im sorry u felt
> like that. as indicated above, i and im sure many others here are
> uninterested in competition, but better solution.
>
>   
I did not mean to be another "vs" thing. Yes, "better solution", the 
goal of open source software.
> im convinced that there is a market for your work. what and how this
> community can leverage it within the context of gwt depends on the
> roadmap of gwt.
>
> best wishes
> ash
> http://www.gworks.com.au
>
>
>   

Regards,
Zhou Renjian