Re: j2s-development] gwt groups post

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

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
>