Re: j2s-development] gwt groups post
Brought to you by:
zhourenjian
Menu
▾
▴
Re: j2s-development] gwt groups post
|
From: Zhou R. <jo...@sj...> - 2006-10-16 17:32:43
|
Zhou Renjian wrote: > 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 > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > j2s-development mailing list > j2s...@li... > https://lists.sourceforge.net/lists/listinfo/j2s-development > > > Hi Ash and all, I am still thinking a little about GWT's Java to JavaScript compiler. And it seems that there are ways for Java2Script compiler to compile Java2Script's SWT applications in GWT-like way. It means that the performance of Java2Script will be improved and *.js file size will be decreased a lot! And there are ways to keep current dynamical module loading and java reflection either. The way I am thinking may be simple for me. It's just a call graph(Concept from GWT) algorithm. First traverse the entry *.java, which has static method main, with an ASTVisitor; Now I now know which classes are required and which methods are called inside main. And as we have all the Java sources, we can traverse down all necessary classes and methods. Actually these classes and methods are in a call graph of the application. After we get the call graph, we can generated those classes, those fields and those method in the call graph! Maybe we do not flat those super calls or polymorphic calls into static unique calls. Keeping it in a more Java way (which may also make the performance a little poor but may be used to implement dynamic loading and java reflection) will also give ways to reusing existed Java2Script Clazz simulator. If classes needed full Java reflection existed, we can mark some smart javaDoc tags on them so the whole things of the given classes are in the call graph. In a result, we can generate whatever we need (But we require some extra configuration when comparing to pure desktop applications development). If we want dynamic modules loading. We may keep those modules together without compiler's call graph algorithm optimization. That is the idea. In my opinion, by reusing existed Java2Script's compiler codes, it may take one developer about 2 ~ 3 months to implement the above call graph algorithm and do the tests. And the loading performance of generated *.js may be optimized to at least 50% (maybe 20%) of current Java2Script's *.js. Actually the file size will be decreased to about 50% or lesser. Why current Java2Script compiler is not compiling Java sources in such a excellent way? As once I mentioned, Java2Script's compiler is designed to compile Java libraries into JavaScript. But the above generated JavaScript files will be project dependent! Two different applications won't share javascript libraries! But maybe with smart designs we may share some common bootstrap codes and more. Any opinions about the above idea? Maybe I am just wrong at some points or in the whole direction? Ash, as once you said, you spent some time trying to integrate GWT and J2S together. Maybe you see something we never see yet. Would you like to share your ideas with us? And what about the above new compiling way of Java2Script compiler if you already have some knowledge of Java2Script compiler? -- Regards, Zhou Renjian http://j2s.sourceforge.net/ Java2Script: Bridge of RCP to RIA Reusing Java codes and tools into JavaScript |
