Re: j2s-development] gwt groups post

[Soheil H. Y. <soh...@gm...>]

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
>