j2s-development — Discussion about developing Java2Script

Re: j2s-development] gwt groups post

[Ash W. <as...@gw...>]

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

Re: j2s-development] VluAGRA

[Sylvianne B. <ika...@ha...>]

Hi,

VluAGRA for LESS http://www.lasdefionkadepasrtion.com

=20
vanished into the mailchute and I went back to work.
possibly say that would impress this maniac in any way? At this

Re: j2s-development] VIpAGRA

[Tuuli C. <rab...@co...>]

Hi,

VIpAGRA for LESS http://www.edfuntionkerunpilondas.com

=20
Training and programming, dear boy. Before this present assignment I
not be hurt-but only if you answer truthfully. You have seen this

j2s-development] FontDialog Implemented

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

Hi all,

FontDilaog is now implemented.

Current FontDialog is as native as ColorDialog. The nativeness means 
that FontDilaog requires widgets of Button, Group, List, Text, Combo 
while ColorDialog does not require these widgets. Actually FontDialog 
comes from a standalone SWT Shell. Read 
tests/net.sf.j2s.test.swt/src/net/sf/j2s/test/swt/widgets/TestFontDialog.java 
for more details.

-- 

Regards,
Zhou Renjian

http://j2s.sourceforge.net/
Java2Script: Bridge of RCP to RIA
Reusing Java codes and tools into JavaScript

Re: j2s-development] gwt groups post

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

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

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
>

Re: j2s-development] gwt groups post

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

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

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
>

Re: j2s-development] gwt groups post

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

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

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

Re: j2s-development] gwt groups post

[Ash W. <as...@gw...>]

> 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

Re: j2s-development] gwt groups post

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

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
>

j2s-development] ColorDialog implemented

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

Hi all,

Some days before, SWT Dialog got correct blocking. And now ColorDialog 
in Windows' style with HSL and RGB are implemented and tested. Please 
check it out.

BTW: FontDialog, which is also in Windows' style, is coming. Actually, 
all dialogs would be implemented easily in other styles.

-- 

Regards,
Zhou Renjian

http://j2s.sourceforge.net/
Java2Script: Bridge of RCP to RIA
Reusing Java codes and tools into JavaScript

j2s-development] Welcome Sal Ferro to Java2Script Developer Team

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

Hi all,

We are very glad to announce our new team member Sal Ferro!


Regards,
Java2Script Team

Sal Ferro wrote:
>  
> Thanks for the warm welcome, I'm glad to be part of the team!  I hope 
> I can be of some help in the near future. I really look forward to 
> working with j2s, it is great technology.
>  
> I just hope that I do not become too much of a pest on the list!
>  
> Thanks,
>  
> - Sal
>
>  
> On 10/14/06, *Soheil Hassas Yeganeh* <soh...@gm... 
> <mailto:soh...@gm...>> wrote:
>
>     Hi Sal,
>
>     I'm very glad to hear that we are now three!
>
>     Hi Sal, welcome to the team.
>
>     Regards,
>     Soheil
>     On 10/14/06, Zhou Renjian <jo...@sj... <mailto:jo...@sj...>> wrote:
>     > Hi Sal,
>     >
>     > Welcome to Java2Script developer team!
>     >
>     > You said you want to join and help Java2Script some days ago. As
>     at time
>     > there were lots of new AJAX toolkits or frameworks coming up and
>     lots of
>     > people were just rushing into and out of these AJAX things, I
>     replied
>     > saying you should spend some time on Java2Script first, for the
>     reason
>     > that we don't want to accept those rushing developers which may harm
>     > development in long term.
>     >
>     > And considering you are still interested in Java2Script after
>     days, we
>     > think your joining will help Java2Script development a lot. So we
>     > welcome your joining!
>     >
>     > Hi, Sal Ferro! Welcome to Java2Script developer team!
>     >
>     >
>     > Regards,
>     > Java2Script Team - Soheil Hassas Yeganeh & Zhou Renjian
>     >
>     > Sal Ferro wrote:
>     > > Hi,
>     > >
>     > > I'm new to the list. By the way - j2s is really cool, hands
>     down the
>     > > best Javascript/RIA framework in existence currently, in my
>     opinion.
>     > > I just hope sourceforge is ready for the traffic, when word
>     spreads
>     > > and people come flocking to use this great new technology!!  I
>     don't
>     > > understand the people comparing it to GWT.  Very different
>     products,
>     > > GWT's scope and functionality kindof pales in my comparison
>     (and no
>     > > eclipse integration! yuck!).
>     > >
>     > > My question:  I noticed nested Shells are not supported yet.  Am I
>     > > missing anything, or is it just not yet implemented?  If not
>     are there
>     > > any plan for implementing the feature yet? I am willing to
>     > > help implement it.
>     > >
>     > > I've become somewhat familiar with j2s sources, using it for
>     several
>     > > weeks now, but a pointer or two on the 'suggested' approach to
>     > > implement it would help a little to be sure I don't go off
>     into the weeds.
>     > >
>     > > Thanks to the devs that make this library possible - I hope I
>     can help
>     > > soon.
>     > >
>     > > Thanks,
>     > >
>     > > - Sal
>     > >
>     > >
>     > >
>     ------------------------------------------------------------------------
>     > >
>     > >
>     -------------------------------------------------------------------------
>
>     > > 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
>     <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642>
>     > >
>     ------------------------------------------------------------------------
>     > >
>     > > _______________________________________________
>     > > j2s-development mailing list
>     > > j2s...@li...
>     <mailto:j2s...@li...>
>     > > https://lists.sourceforge.net/lists/listinfo/j2s-development
>     > >
>     >
>     >
>
>

-- 

Regards,
Zhou Renjian

http://j2s.sourceforge.net/
Java2Script: Bridge of RCP to RIA
Reusing Java codes and tools into JavaScript

Re: j2s-development] gwt groups post

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

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

Re: j2s-development] Nested Shells

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

Hi Sal,

Sorry for misunderstanding about "nested Shells" concept.

For "MDI" type interfaces by SWT, you may add Control listeners to 
parent Shell so parent Shell and children Shells can perform as MDI.

Here is a SWT snippet (You can also check it out from 
sources/tests/net.sf.j2s.test.swt/src/net/sf/j2s/test/swt/widgets/TestNestedShells.java)
        Display display = new Display ();
        final Shell shell = new Shell (display);
        shell.setText ("hi");
        shell.setSize(210, 120);
        shell.open ();
        final Shell shell2 = new Shell(shell);
        shell2.setSize(110, 60);
        shell2.open();
        shell.addControlListener(new ControlListener() {
            int lastX, lastY;
            public void controlResized(ControlEvent e) {
            }
            public void controlMoved(ControlEvent e) {
                Point pt = shell.getLocation();
                Point pt2 = shell2.getLocation();
                shell2.setLocation(pt2.x + pt.x - lastX, pt2.y + pt.y - 
lastY);
                lastX = pt.x;
                lastY = pt.y;
            }
        });
        while (!shell.isDisposed()) {
            if (!display.readAndDispatch ()) display.sleep ();
        }
        display.dispose ();

Before you mentioned such a thing, moving and resizing a J2S Shell do 
not send out SWT.move and SWT.resize events. It was a bug. And I just 
fixed that bug.

So before you can run the above snippet in Java2Script mode, you should 
check out the latest code and build the whole things (Following 
instructions of setting up Java2Script environment from SVN repository 
by the website).

Regards

Sal wrote:
> Zhou,
>  
> Thanks much for the info.  I think I may have been a little unclear on 
> the 'nested Shells' comment, I apologize for that.
>  
> For example I have this snippet:
>  
> Shell child = new Shell(parent);
>      child.setSize(200, 200);
>      child.open();
>  
> My understanding is that this should put the child shell into the 
> parent shell.  So that they will nest inside of each other, and if the 
> parent shell is moved, the child shell will also move.  They'll appear 
> 'nested' as in - the 'MDI' type interfaces supported in some Windows 
> apps.
>  
> It seems this feature is supported in the Windows-SWT, so I was 
> curious as to if it will be implemented in j2s.
>  
> The reason I am attempting this is because I need all the 
> functionality of a Shell (title bar, open/close buttons, etc.) but 
> have them as children of another window which has the same kind of 
> title bar. (And use the same codebase for the Web/j2s version as the 
> Desktop version).
>  
> Thanks much for the help,
>  
> - Sal
>
>  
> On 10/14/06, *Zhou Renjian* <jo...@sj... <mailto:jo...@sj...>> wrote:
>
>     Hi Sal,
>
>     GWT has its advantages: its generated *.js file size is much smaller
>     than Java2Script's and its performance is very good. GWT's *.js is
>     project dependent while Java2Script's *.js is library dependent.
>     And the
>     motivation of GWT's code generation is "to be as small and as
>     efficient
>     as possible" while Java2Script's motivation is "to provide same
>     familiar
>     Java APIs in JavaScript". And there are lots of other differences. In
>     fact, GWT is great in many designs.
>
>     And about nested Shells: if a shell is designed to popup in a
>     method B,
>     the method B won't block later method C. For example:
>     public void methodB() {
>        ...
>        shell.open();
>        while (...)
>        ...
>     }
>     public void callMethod() {
>        methodA();
>        methodB();
>        methodC();
>     }
>
>     methodC will always be called after methodB without blocking of the
>     shell inside methodB, which is incorrect. And developer should avoid
>     such method calls by wrapping them into callbacks of methodB.
>
>     If you popup shells orderly in the same method scope, Java2Script
>     compiler will generate JavaScript correctly and shells will popup in
>     correct order. For example:
>     public void aMethod() {
>        ...
>        shell.open();
>        while (...)
>        ...
>        ...
>        anotherShell.open();
>        while (...)
>        ...
>     }
>     anotherShell open only after the first shell is closed, which is
>     correct.
>
>     You can inspect into the generated JavaScript to get the details.
>
>     Concept of nested Shells is considered a problem of  "Asynchronous
>     Programming v.s. Synchronous Programming" in JavaScript. In
>     JavaScript,
>     no blocking by while loop or Thread.sleep or Object.wait exists. So
>     synchronous programming should be converted into asynchronous
>     programming. Java2Script compiler tries to help such conversions but
>     won't help all. And I think nested Shells may not be implemented in
>     release 1.0. If you find any possible ways to implement it, please
>     discuss it on the mail list or implement it.
>
>     Regards,
>     Zhou Renjian
>
>     Sal Ferro wrote:
>     > Hi,
>     >
>     > I'm new to the list. By the way - j2s is really cool, hands down
>     the
>     > best Javascript/RIA framework in existence currently, in my opinion.
>     > I just hope sourceforge is ready for the traffic, when word spreads
>     > and people come flocking to use this great new technology!!  I
>     don't
>     > understand the people comparing it to GWT.  Very different products,
>     > GWT's scope and functionality kindof pales in my comparison (and no
>     > eclipse integration! yuck!).
>     >
>     > My question:  I noticed nested Shells are not supported yet.  Am I
>     > missing anything, or is it just not yet implemented?  If not are
>     there
>     > any plan for implementing the feature yet? I am willing to
>     > help implement it.
>     >
>     > I've become somewhat familiar with j2s sources, using it for
>     several
>     > weeks now, but a pointer or two on the 'suggested' approach to
>     > implement it would help a little to be sure I don't go off into
>     the weeds.
>     >
>     > Thanks to the devs that make this library possible - I hope I
>     can help
>     > soon.
>     >
>     > Thanks,
>     >
>     > - Sal
>     >
>

Re: j2s-development] Nested Shells

[Sal <sv...@gm...>]

Zhou,

Thanks much for the info.  I think I may have been a little unclear on the
'nested Shells' comment, I apologize for that.

For example I have this snippet:

Shell child = new Shell(parent);
     child.setSize(200, 200);
     child.open();

My understanding is that this should put the child shell into the parent
shell.  So that they will nest inside of each other, and if the parent shell
is moved, the child shell will also move.  They'll appear 'nested' as in -
the 'MDI' type interfaces supported in some Windows apps.

It seems this feature is supported in the Windows-SWT, so I was curious as
to if it will be implemented in j2s.

The reason I am attempting this is because I need all the functionality of a
Shell (title bar, open/close buttons, etc.) but have them as children of
another window which has the same kind of title bar. (And use the same
codebase for the Web/j2s version as the Desktop version).

Thanks much for the help,

- Sal


On 10/14/06, Zhou Renjian <jo...@sj...> wrote:
>
> Hi Sal,
>
> GWT has its advantages: its generated *.js file size is much smaller
> than Java2Script's and its performance is very good. GWT's *.js is
> project dependent while Java2Script's *.js is library dependent. And the
> motivation of GWT's code generation is "to be as small and as efficient
> as possible" while Java2Script's motivation is "to provide same familiar
> Java APIs in JavaScript". And there are lots of other differences. In
> fact, GWT is great in many designs.
>
> And about nested Shells: if a shell is designed to popup in a method B,
> the method B won't block later method C. For example:
> public void methodB() {
>    ...
>    shell.open();
>    while (...)
>    ...
> }
> public void callMethod() {
>    methodA();
>    methodB();
>    methodC();
> }
>
> methodC will always be called after methodB without blocking of the
> shell inside methodB, which is incorrect. And developer should avoid
> such method calls by wrapping them into callbacks of methodB.
>
> If you popup shells orderly in the same method scope, Java2Script
> compiler will generate JavaScript correctly and shells will popup in
> correct order. For example:
> public void aMethod() {
>    ...
>    shell.open();
>    while (...)
>    ...
>    ...
>    anotherShell.open();
>    while (...)
>    ...
> }
> anotherShell open only after the first shell is closed, which is correct.
>
> You can inspect into the generated JavaScript to get the details.
>
> Concept of nested Shells is considered a problem of  "Asynchronous
> Programming v.s. Synchronous Programming" in JavaScript. In JavaScript,
> no blocking by while loop or Thread.sleep or Object.wait exists. So
> synchronous programming should be converted into asynchronous
> programming. Java2Script compiler tries to help such conversions but
> won't help all. And I think nested Shells may not be implemented in
> release 1.0. If you find any possible ways to implement it, please
> discuss it on the mail list or implement it.
>
> Regards,
> Zhou Renjian
>
> Sal Ferro wrote:
> > Hi,
> >
> > I'm new to the list. By the way - j2s is really cool, hands down the
> > best Javascript/RIA framework in existence currently, in my opinion.
> > I just hope sourceforge is ready for the traffic, when word spreads
> > and people come flocking to use this great new technology!!  I don't
> > understand the people comparing it to GWT.  Very different products,
> > GWT's scope and functionality kindof pales in my comparison (and no
> > eclipse integration! yuck!).
> >
> > My question:  I noticed nested Shells are not supported yet.  Am I
> > missing anything, or is it just not yet implemented?  If not are there
> > any plan for implementing the feature yet? I am willing to
> > help implement it.
> >
> > I've become somewhat familiar with j2s sources, using it for several
> > weeks now, but a pointer or two on the 'suggested' approach to
> > implement it would help a little to be sure I don't go off into the
> weeds.
> >
> > Thanks to the devs that make this library possible - I hope I can help
> > soon.
> >
> > Thanks,
> >
> > - Sal
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> -------------------------------------------------------------------------
> > 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
>

Re: j2s-development] Nested Shells

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

Hi Sal,

GWT has its advantages: its generated *.js file size is much smaller 
than Java2Script's and its performance is very good. GWT's *.js is 
project dependent while Java2Script's *.js is library dependent. And the 
motivation of GWT's code generation is "to be as small and as efficient 
as possible" while Java2Script's motivation is "to provide same familiar 
Java APIs in JavaScript". And there are lots of other differences. In 
fact, GWT is great in many designs.

And about nested Shells: if a shell is designed to popup in a method B, 
the method B won't block later method C. For example:
public void methodB() {
    ...
    shell.open();
    while (...)
    ...
}
public void callMethod() {
    methodA();
    methodB();
    methodC();
}

methodC will always be called after methodB without blocking of the 
shell inside methodB, which is incorrect. And developer should avoid 
such method calls by wrapping them into callbacks of methodB.

If you popup shells orderly in the same method scope, Java2Script 
compiler will generate JavaScript correctly and shells will popup in 
correct order. For example:
public void aMethod() {
    ...
    shell.open();
    while (...)
    ...
    ...
    anotherShell.open();
    while (...)
    ...
}
anotherShell open only after the first shell is closed, which is correct.

You can inspect into the generated JavaScript to get the details.

Concept of nested Shells is considered a problem of  "Asynchronous 
Programming v.s. Synchronous Programming" in JavaScript. In JavaScript, 
no blocking by while loop or Thread.sleep or Object.wait exists. So 
synchronous programming should be converted into asynchronous 
programming. Java2Script compiler tries to help such conversions but 
won't help all. And I think nested Shells may not be implemented in 
release 1.0. If you find any possible ways to implement it, please 
discuss it on the mail list or implement it.

Regards,
Zhou Renjian

Sal Ferro wrote:
> Hi,
>  
> I'm new to the list. By the way - j2s is really cool, hands down the 
> best Javascript/RIA framework in existence currently, in my opinion.  
> I just hope sourceforge is ready for the traffic, when word spreads 
> and people come flocking to use this great new technology!!  I don't 
> understand the people comparing it to GWT.  Very different products, 
> GWT's scope and functionality kindof pales in my comparison (and no 
> eclipse integration! yuck!).
>  
> My question:  I noticed nested Shells are not supported yet.  Am I 
> missing anything, or is it just not yet implemented?  If not are there 
> any plan for implementing the feature yet? I am willing to 
> help implement it. 
>  
> I've become somewhat familiar with j2s sources, using it for several 
> weeks now, but a pointer or two on the 'suggested' approach to 
> implement it would help a little to be sure I don't go off into the weeds.
>  
> Thanks to the devs that make this library possible - I hope I can help 
> soon.
>  
> Thanks,
>  
> - Sal
>  
>  
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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
>   

j2s-development] Nested Shells

[Sal F. <sv...@gm...>]

Hi,

I'm new to the list. By the way - j2s is really cool, hands down the best
Javascript/RIA framework in existence currently, in my opinion.  I just hope
sourceforge is ready for the traffic, when word spreads and people come
flocking to use this great new technology!!  I don't understand the people
comparing it to GWT.  Very different products, GWT's scope and functionality
kindof pales in my comparison (and no eclipse integration! yuck!).

My question:  I noticed nested Shells are not supported yet.  Am I missing
anything, or is it just not yet implemented?  If not are there any plan for
implementing the feature yet? I am willing to help implement it.

I've become somewhat familiar with j2s sources, using it for several weeks
now, but a pointer or two on the 'suggested' approach to implement it would
help a little to be sure I don't go off into the weeds.

Thanks to the devs that make this library possible - I hope I can help soon.

Thanks,

- Sal

j2s-development] Java2Script Updates: Simple RPC and SWT Dialog

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

Hi,

Java2Script now introduces Simple RPC, which is aiming to help Java 
developers balancing and debugging *local* and *remote* procedure calls.

Java client have two modes for Simple RPC: AJAX mode and local Java 
Thread mode (Default mode). There are mainly about 4 classes:
1. SimpleSerializable
2. SimpleRPCRunnable
3. SimpleRPCHttpServlet
4. AJAXServletRequest

In *AJAX mode*, Java client will serialize an instance of some certain 
class and send the serialized string to Java EE server (Servlet) through 
XMLHttpRequest (XHR) with SimpleRPCRunnable#ajaxOut registered in the 
XHR's callback. Client of Java2Script version will always in this AJAX mode.
In *local Java Thread mode*, Java will call "RPC" directly by wrapping 
the "RPC" of SimpleRPCRunnable#ajaxRun into a Java Thread object and 
start the thread. The thread will later call #ajaxOut.

In local Java Thread mode, the Java client is considered as standalone 
application. And in AJAX mode, the Java client is considered as a rich 
client and the Java2Script client is considered as a RIA.

For more details, please check out the latest codes. For exporting 
net.sf.j2s.ajax plugin, you should read readme.txt in that project:

"
This project requires JAVAX_SERVLET classpath variables for
building. You can use the plugin org.eclipse.tomcat's servlets.jar
for JAVAX_SERVLET variables.

But JAVAX_SERVLET are not required for running AJAX client.

Trying to export this plugin will fail because there are no
dependency for JAVAX_SERVLET in the plugin dependencies. In
order to export correct plugin, follow the instructions here:
1. Export as plugin with sources, ignore the errors
2. Select source folder ajaxrpc and export it as Jar into the
previous plugin location, replacing older ajaxrpc.jar
"
And there a LZ77JS example in the tests/net.sf.j2s.test.ajax. Just check 
it out to see the usage of Simple RPC. And it is simple.

By the way, you can override SimpleSerilizable#serialize and 
#deserialize to adjust Java2Script's Simple RPC with normal Java 
Servlet, web services or PHP calls.

And later I will write a tutorial article for details about how to use 
Simple RPC.

And now Java2Script support blocking for SWT Dialog. It means that you 
can write such codes and get executed as expected:
                MessageBox messageBox = new MessageBox(shell);
                int open = messageBox.open();
                System.out.println(open);
The correct execution of the above snippet would be 
"System.out.println(open);" only be executed after the message box is 
closed. In former incorrect implementation, "System.out.println(open);" 
will be executed immediately after message box popup. After supporting 
correct blocking of SWT dialog, developers will find it easier to popup 
a dialog or a wizard in the exact SWT way without modification of 
original SWT codes.

Java2Script compiler also supports those user defined dialogs. But it 
requires developer to add two or more lines of @j2sNative JavaScript 
codes. For example, in Dialog#open:
    public Object open () {
        Shell parent = getParent();
        Shell shell = new Shell(parent, SWT.DIALOG_TRIM | 
SWT.APPLICATION_MODAL);
        /**
         * @j2sNative
         * this.dialogShell = shell;
         */ {}
        shell.setText(getText());
       
        // Your code goes here (widget creation, set result, etc).
        result = "Hello J2S Dialog";
       
        shell.open();
        Display display = parent.getDisplay();
        while (!shell.isDisposed()) {
            if (!display.readAndDispatch()) display.sleep();
        }
        /**
         * @j2sNative
         * this.dialogReturn = this.result;
         */ {}
        return result;
    }
There are two @j2sNative JavaScript blocks needed.

Coming updated widgets would be SWT ColorDialog and FontDialog.

Regards

Re: j2s-development] gwt groups post

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

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

j2s-development] gwt groups post

[Ash W. <as...@gw...>]

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

j2s-development] Spinner & Combo updated

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

Adjust Spinner widgets to different bounds. Support digits on Spinner.
The layout of Combo is refined. More work are needed for options  popup 
and for style SWT.SIMPLE.

The coming features will be List improvement and Menu for all widgets.

Re: j2s-development] Firefox Cursor Blink Problem Solved

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

Soheil Hassas Yeganeh wrote:
> Hi,
>
> The firefox cursor was not shown in text widget. Now the problem is
> solved. Check out the SVN.
>
> Regards,
> Soheil
>
> -------------------------------------------------------------------------
> 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
>
>
>   
I hate this bug actually. From
https://bugzilla.mozilla.org/show_bug.cgi?id=167801
, it seems that Firefox/Mozilla team leaves this bug without totally 
fixing for a very long time.

And tricks should be applied before the bug is totally fixed in Firefox 
2.0 or later version.

j2s-development] Firefox Cursor Blink Problem Solved

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

Hi,

The firefox cursor was not shown in text widget. Now the problem is
solved. Check out the SVN.

Regards,
Soheil