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-17 17:09:04
|
When I first met the concept of Dojo js linker, I didn't think it has the capability to link things correctly for the generated *.js of Java2Script compiler. It's something.like GNU linker won't be able to link those *.obj generated by MSVC compiler. But their algorithm may be excellent. And maybe later I should take a study on it. By the way, JavaScript now has its compiler, linker, and executable output (?), simulator(?), maybe later VM, workbench, ... It seems that JavaScript is over-used according the original design of Brendan. Soheil Hassas Yeganeh wrote: > Ok I got the problem. > Did you see jslinker that AOL has donated to the Dojo toolkit ? For > unreachable code or any other things like this, its possible to use > their linker. But I really doubt about the license. > The jslinker svn repository is available at > http://svn.dojotoolkit.org/dojo/trunk/tools/jslinker > > Regards, > Soheil > On 10/17/06, Zhou Renjian <jo...@sj...> wrote: > >> Soheil Hassas Yeganeh wrote: >> >>> Hi Zhou, >>> >>> I doubt about the graph model. >>> In Clazz.searchAndExecuteMethod, that was really very slow, you'd done >>> a lot of performance enhancing works. The most important change you'd >>> made is a cache for methods. After the first call to method >>> invocation, Clazz will cache it and do not search again for the same >>> method invocation. So, after the first call, methods are cached and >>> perform faster. >>> So, what does graph model do for us? Is it just a compile time cache? >>> like the hotspot! or any other enhancement you mean ? >>> >>> Regards, >>> Soheil >>> >>> >>> >> I just mean reducing the *.js file size. >> >> The call graph concept is about something that how wide the application >> can branch its method calls to. For example, if there are a public >> method M in classs C, by current Java2Script compiler, method M in class >> C will be compiled into JavaScript even the method M will never be >> called by application. But in GWT compiler, if method M are not reached >> by application, GWT compiler won't generate JavaScript for method M. So >> such a call graph algorithm will result in smaller *.js file size. >> Smaller file size may decrease the time needed between client and >> server. And browser initializing method blocks and J2SClazz simulator >> registering method for a class also require CPU time. So in all, by such >> call graph algorithm, performance should be improved. >> >> The above call graph algorithm is a compile time algorithm, nothing >> about hotspot. >> >> In current Java2Script compiler and J2SClazz simulator, they are twisted >> with each other tightly. It seemed that I left too much works on >> JavaScript's Clazz#searchAndExecuteMethod and resulted in a very bad >> performance after all. Maybe the compiler should do more works so >> simulator can do less works to improve performance. That would be a >> right way for further improvement. >> >> And actually there should be a trade-off between compiler and simulator. >> The more we rely on compiler, the fewer information simulator gets, and >> maybe faster will the application run. >> >> >>> On 10/16/06, Zhou Renjian <jo...@sj...> wrote: >>> >>> >>>> 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 >>>> >>>> > |
