Thread: j2s-development] gwt groups post
Brought to you by:
zhourenjian
Menu
▾
▴
j2s-development
|
From: Ash W. <as...@gw...> - 2006-10-06 09:08:36
|
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. 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 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 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. > 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) * 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. * 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 --- 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. 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 |
|
From: Zhou R. <jo...@sj...> - 2006-10-07 16:52:13
|
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 |
|
From: Soheil H. Y. <soh...@gm...> - 2006-10-17 05:51:17
|
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 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 > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > j2s-development mailing list > j2s...@li... > https://lists.sourceforge.net/lists/listinfo/j2s-development > |
|
From: Ash W. <as...@gw...> - 2006-10-17 10:56:25
|
> 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. hey Zhou, this is great news. i really plan to follow up on this thread in a day or so. i am currently way under prepared to deliver a presentation on GWT tomorrow so i dont have time at the moment. see http://www.slatteryit.com.au/eja_industry_forum_melb.html > 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 the one thing that i would like you and your community to consider is what the _real_ value proposition of j2c is. the tension that i personally experience with j2c is that i see a great opportunity to address a void in gwt that will likely never be addressed. but then i reconsider it and feel that it is orthogonal to you and your communities goals. i believe what you have engineered is fantastic, but is it solving the right problem? more on this later. i wanted to ping u back so that u didnt think i lost interest in the thread. best wishes ash http://www.gworks.com.au |
|
From: Zhou R. <jo...@sj...> - 2006-10-17 13:03:28
|
Ash Wima wrote: >> 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. >> > > hey Zhou, > > this is great news. i really plan to follow up on this thread in a day > or so. i am currently way under prepared to deliver a presentation on > GWT tomorrow so i dont have time at the moment. > > see http://www.slatteryit.com.au/eja_industry_forum_melb.html > > > >> 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 >> > > the one thing that i would like you and your community to consider is > what the _real_ value proposition of j2c is. > Well, this is a big question for Java2Script compiler. > the tension that i personally experience with j2c is that i see a > great opportunity to address a void in gwt that will likely never be > addressed. but then i reconsider it and feel that it is orthogonal to > you and your communities goals. > > i believe what you have engineered is fantastic, but is it solving the > right problem? > Some words: What is the right problem? That is actually a big question not only just for me, may be also for you and for all AJAX toolkit and framework designers. Yes, from my early experience, 200k+ *.js will be reached very easily for AJAX applications. So when Java2Script generated about 400k+ *.js for java.util.* and SWT.libraries, I just took it for granted. :) In my early thoughts, such size of *.js was OK for rich *Intranet* applications. And in early days of Java2Script, I took fast development and deployment as an inner goal. It seemed at that time I accepted that fast developed or easily mantained solutions are more likely to be accepted. And I am sure want to hear what is your or your customers' problems over java to javascript RIA solutions. > more on this later. i wanted to ping u back so that u didnt think i > lost interest in the thread. > > If your representation will be published online, please let GWT group and us know. > best wishes > ash > http://www.gworks.com.au > > ------------------------------------------------------------------------- > > > -- Regards, Zhou Renjian http://j2s.sourceforge.net/ Java2Script: Bridge of RCP to RIA Reusing Java codes and tools into JavaScript |
|
From: Soheil H. Y. <soh...@gm...> - 2006-10-17 14:31:27
|
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 > >> > >> ------------------------------------------------------------------------- > >> Using Tomcat but need to do more? Need to support web services, security? > >> Get stuff done quickly with pre-integrated technology to make your job easier > >> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > >> _______________________________________________ > >> j2s-development mailing list > >> j2s...@li... > >> https://lists.sourceforge.net/lists/listinfo/j2s-development > >> > >> > > > > ------------------------------------------------------------------------- > > Using Tomcat but need to do more? Need to support web services, security? > > Get stuff done quickly with pre-integrated technology to make your job easier > > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > _______________________________________________ > > j2s-development mailing list > > j2s...@li... > > https://lists.sourceforge.net/lists/listinfo/j2s-development > > > > > > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > j2s-development mailing list > j2s...@li... > https://lists.sourceforge.net/lists/listinfo/j2s-development > |
|
From: Soheil H. Y. <soh...@gm...> - 2006-10-17 18:41:09
|
I mean the same thing. I mean we can just their javascript parser implemented in jslink, to build the graph model and then optimize the code, but i really doubt about the license whether we can change the code and distribute it or not! They have JS AST, and I think we can use it as the graph model or call hierarchy in the project. Regards, Soheil On 10/17/06, Zhou Renjian <jo...@sj...> wrote: > 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 > >>>> > >>>> > > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > j2s-development mailing list > j2s...@li... > https://lists.sourceforge.net/lists/listinfo/j2s-development > |
|
From: Zhou R. <jo...@sj...> - 2006-10-17 21:26:31
|
No, we already have Eclipse Java AST which is much more robust than their JS AST. We can directly design our linker in Java level not in generated JavaScript level. In my opinion, Dojo is JavaScript for Java, while Java2Script is Java to JavaScript. These two toolkits see things differently. Soheil Hassas Yeganeh wrote: > I mean the same thing. > I mean we can just their javascript parser implemented in jslink, to > build the graph model and then optimize the code, but i really doubt > about the license whether we can change the code and distribute it or > not! > They have JS AST, and I think we can use it as the graph model or call > hierarchy in the project. > Regards, > Soheil > > On 10/17/06, Zhou Renjian <jo...@sj...> wrote: > >> 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. >>>> >>>> >>>> |
|
From: Ash W. <as...@gw...> - 2006-10-22 08:20:00
|
hi zhou, as i type this response i cant help but feel that this discussion is a distraction from you remaining focused on delivering your two remaining milestones. i want to see you complete this achievement as much as any other member in your community. i thought that it is important to first focus on the business problem rather the techincal problem. hence, i would like to return to the statement that i ended the last message with: "is the right problem was being solved?" the reason why i keep returning here is because i also keep arriving at the same answers to the following problems: Problem 1. ---------- if you had a desktop java application (or you are an enterprise with a significant investment in java desktop apps), what is the most effective way of making that application available on a browser and reduce the total cost of ownership? if feel that if xml11 was more mature, then that would be my preferred option. why did i not choose j2s? well xml11 is more about taking an existing asset (unchanged), and remoting its display like X11. if i represented the business, i would not want IT to take an existing asset, create a derivative asset, fully test the new derivative work and now pay for the ongoing operations and maintenance of both assets with zero additional business value. Problem 2. ---------- if you need to build a new RIA application, what is the most effective way to improve time-to-market and quality to reduce the total cost of ownership? i feel that gwt with gwt-designer is the preferred option. why did i not choose j2s? well gwt lets me leverage java resources, does not require me to retool, enables me to debug the client in pure java, has a large OSS community around it with commercial sponsorship, has a third party visual designer tool to support it, and promotes simplexity. --- what i find paradoxical is that i like your work so much, yet i wouldnt choose it to solve either of the two problems above. this is elaborated in my presentation[1] that i delivered. please review slides 3, 4 & 5 in the cited document. what you will notice from these slides is that on my 6 month journey, i concluded that j2s is the technology that fits my motivation profile best. i have always said, that there is so much that you are doing right, but because i believe your technology sits somewhere between Problem 1 and Problem 2, you are effectively solving a problem that i do not share. hence, my question to you and your community, "are you solving the right problem?". after you deliver release 1 of j2s, i hope that you get the opportunity to reevaluate the position of the technology. --- as part of my presentation to the enterprise java forum i decided to develop a jee application that showcased gwt. i chose to create gwt-Petstore[2], a gwt implementation of the classic Sun Java Petstore. i have often wondered what an swt implementation of Petstore would look like when rendered with j2s. i have tried to imagine web consumers using the j2s implementation :-). what i have concluded is that gwt needs to be spiced up with classic desk widgets, but j2s also needs to be spiced up with broshureware web widgets. when you start adding features like broshureware web widgets and simple rpc, i feel like you are stretching the motivations of rcp. to me you are now creating a new beast - one that i feel has an identity crisis! --- zhou, i want to remind you that these are just one guys crazy thoughts. i may well be completely wrong. btw, sorry to keep you waiting so long for the reply. rgds ash http://www.gworks.com.au 1. http://ashinw.googlepages.com/EJA_GWT_presentation.ppt 2. http://code.google.com/p/gwtpetstore/ 3. http://gwtpetstore.googlecode.com/svn/trunk |
|
From: Zhou R. <jo...@sj...> - 2006-10-22 13:13:43
|
Ash Wima wrote: > hi zhou, > > as i type this response i cant help but feel that this discussion is a > distraction from you remaining focused on delivering your two > remaining milestones. i want to see you complete this achievement as > much as any other member in your community. > > i thought that it is important to first focus on the business problem > rather the techincal problem. hence, i would like to return to the > statement that i ended the last message with: "is the right problem > was being solved?" > > the reason why i keep returning here is because i also keep arriving > at the same answers to the following problems: > > Problem 1. > ---------- > if you had a desktop java application (or you are an enterprise with a > significant investment in java desktop apps), what is the most > effective way of making that application available on a browser and > reduce the total cost of ownership? > > if feel that if xml11 was more mature, then that would be my preferred option. > > why did i not choose j2s? > well xml11 is more about taking an existing asset (unchanged), and > remoting its display like X11. if i represented the business, i would > not want IT to take an existing asset, create a derivative asset, > fully test the new derivative work and now pay for the ongoing > operations and maintenance of both assets with zero additional > business value. > > > Problem 2. > ---------- > if you need to build a new RIA application, what is the most effective > way to improve time-to-market and quality to reduce the total cost of > ownership? > > i feel that gwt with gwt-designer is the preferred option. > > why did i not choose j2s? > well gwt lets me leverage java resources, does not require me to > retool, enables me to debug the client in pure java, has a large OSS > community around it with commercial sponsorship, has a third party > visual designer tool to support it, and promotes simplexity. > > --- > > what i find paradoxical is that i like your work so much, yet i > wouldnt choose it to solve either of the two problems above. this is > elaborated in my presentation[1] that i delivered. please review > slides 3, 4 & 5 in the cited document. > > what you will notice from these slides is that on my 6 month journey, > i concluded that j2s is the technology that fits my motivation profile > best. i have always said, that there is so much that you are doing > right, but because i believe your technology sits somewhere between > Problem 1 and Problem 2, you are effectively solving a problem that i > do not share. hence, my question to you and your community, "are you > solving the right problem?". > > > after you deliver release 1 of j2s, i hope that you get the > opportunity to reevaluate the position of the technology. > > > --- > > as part of my presentation to the enterprise java forum i decided to > develop a jee application that showcased gwt. i chose to create > gwt-Petstore[2], a gwt implementation of the classic Sun Java > Petstore. i have often wondered what an swt implementation of Petstore > would look like when rendered with j2s. i have tried to imagine web > consumers using the j2s implementation :-). what i have concluded is > that gwt needs to be spiced up with classic desk widgets, but j2s also > needs to be spiced up with broshureware web widgets. > > when you start adding features like broshureware web widgets and > simple rpc, i feel like you are stretching the motivations of rcp. to > me you are now creating a new beast - one that i feel has an identity > crisis! > > --- > > zhou, i want to remind you that these are just one guys crazy > thoughts. i may well be completely wrong. > > btw, sorry to keep you waiting so long for the reply. > > > rgds ash > http://www.gworks.com.au > > 1. http://ashinw.googlepages.com/EJA_GWT_presentation.ppt > 2. http://code.google.com/p/gwtpetstore/ > 3. http://gwtpetstore.googlecode.com/svn/trunk > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > j2s-development mailing list > j2s...@li... > https://lists.sourceforge.net/lists/listinfo/j2s-development > > > Hi Ash, Thanks for your response. Thanks for your view of problems. And I agree with those "why not j2s" reasons after thinking about them for a while. Exporting old existed desktop applications purely does not add new business values but requires maintenance. And maybe few people take such exporting tries. And about developing new RIAs, SWT is not a right choice. And RIAs and desktop applications are a lot different. And more about exporting old assets, if old desktop applications can be refactored into web applications, it will surely add new values. Lots of open source Java desktop applications may be in this scope of consideration (http://eclipse.org/proposals/rap/ thinks about Eclipse RCP directly). But lots of those desktop application projects are Swing based. And Swing is another thing for Java2Script but only be considered after in release of 1.0. And the next milestone of Java2Script is delayed because some key features (most are SWT-related) are still not implemented. And we j2s team will try to catch up with release schedule. And about RPC, which maybe a new beast as you mentioned, it is an early scheduled key feature. Even though I once considered removing it from Java2Script 1.0 feature list, I implemented it as "Simple", hoping it won't become too complicate. Regards -- Regards, Zhou Renjian http://j2s.sourceforge.net/ Java2Script: Bridge of RCP to RIA Reusing Java codes and tools into JavaScript |
|
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 |
|
From: Zhou R. <jo...@sj...> - 2006-10-17 12:02:57
|
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 >> >> ------------------------------------------------------------------------- >> Using Tomcat but need to do more? Need to support web services, security? >> Get stuff done quickly with pre-integrated technology to make your job easier >> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >> _______________________________________________ >> j2s-development mailing list >> j2s...@li... >> https://lists.sourceforge.net/lists/listinfo/j2s-development >> >> > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > j2s-development mailing list > j2s...@li... > https://lists.sourceforge.net/lists/listinfo/j2s-development > > > |
|
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 >>>> >>>> > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X