Re: j2s-development] gwt groups post

[Zhou R. <jo...@sj...>]

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
>
>
>