Category Archives: SWT

Performance Matters or Not

Posted on September 24, 2007 by Zhou Renjian

Joel Spolsky had a post “Strategy Letter VI“. And I did agree with him to some degree when reading the post. And I decided to write a post about these opinions related to Java2Script later in the evening. And later in evening I found that Ajaxian’s Ben Galbraith posted his opinions but with title “Go Ajax, Young Man“. Well, the title said something already.

Here follows the Java2Script performance issues and SDK concerns.

Right now, performance is a really big matter to Java2Script. But does performance matter a lot in the future? That is a question.

Java2Script was open sourced in late of 2005. And now, 2 years has passed. And Firefox 2.0 is already released, while 2 year ago, it was still in its 1.0. And I could tell that the browser is improved a lot. OK, as I have paid lots of efforts in improving Java2Script performance, I think I would rather bet on the improvement of browser, the improvement of JavaScript engine (such as upgrading to Adobe’s script engine), upgrading of CPU and machine.

About performance, maybe a lot of developers complain that Java is slow. In fact, a lot of developer complains that Eclipse, which is Java based, is very slow and could not stand for it. But Java is still a language used by most of the developers in the last 4 or 5 years. And JavaScript is a language that is much slower than other language. But in recent three years, it is getting hotter and hotter in the format of AJAX development. No matter how slow it is.

Back to Java2Script. Java2Script compile Java sources to JavaScript, and Java2Script supports a port of desktop SWT library in JavaScript besides supporting most common java.* classes. The compilation from Java to JavaScript is done in a Java-way, that is to say, all information in Java sources are preserved in JavaScript, so lots of Java information and features are reserved, including Java reflection. And SWT library is considered a heavy weight library for JavaScript, as it was once designed for desktop application, not for web application.

Now come to comparison of Google Web Toolkit (GWT). GWT is a similar project when comparing to Java2Script. It contains a Java to JavaScript compiler, and supports a set of basic java.* libraries and a set of UI library. But the compilation of Java to JavaScript is not in the same way of Java2Script. It is in a C-way. It links all related JavaScript into a big JavaScript file. And those unrelated (unused) JavaScript are left without packing into the big JavaScript file. So you can not retrieve the Java class information from the final *.js file. But as compiling in C-way, the final *.js is a lot smaller than Java2Script’s *.js. And it also runs a lot faster than Java2Script’s. And the UI library of GWT is a new set of APIs. It is designed for web applications in browser only. So it is more browser-oriented and much more light weighted. In such a way, GWT’s performance is far faster than Java2Script. So few people cares about GWT’s performance.

In some simple words:
Java2Script is not optimized with more heavy weight SDK APIs
GWT is optimized in compiling with a light weight SDK APIs.

In fact, GWT is 100 times more popular than Java2Script at this writing time. So that means performance do matters. But what about 2 more years later? Is there any possibilities that GWT’s APIs is out and GWT’s early performance optimization is lagged behind the improvement of hardware and browser? Maybe later, AJAX developments prove that those optimized compiled *.js is not the trends, and web applications oriented UI APIs is not the trends for richer applications. But no one knows now. So as Ben Galbraith said:

it’s hard to dispute that in a year or two, JavaScript will be much, much faster.

BTW: Java2Script 1.0.0 is to be released by the end of this September, even though performance is still a big problem (but not a huge problem now).

For more discussions, you may want to read early Java to JavaScript compiler discussions

Posted in Architecture, GWT, Hacks, JavaScript, SWT | 3 Comments

Demo: Java2Script Google Talk in SWT

Posted on July 30, 2007 by Zhou Renjian

Pre-words

In March, I wrote “Java2Script version of Google Talk”. It was a very simple SWT application that talks to talk.google.com using Jabber XMPP protocol by Smack library.

About 3 months later, I rewrote the whole Java2Script version of Google Talk. In this time, I still used Smack library. But I used Instantiations’ Windows Builder Pro to help me to design the whole interface. And this time, it copied all existed UI from the desktop version of Google Talk, including every dialogs, menus or layouts. It looks almost exactly the same of Google Talk.

Here is the demo addres: http://demo.java2script.org/gtalk/

P.S. Other available web IM services provided by this Java2Script technologies:

Here are some screenshots:

Click for Large Screenshot: Google Talk Client’s JavaScript Copy

Requirements

It is just trying to re-implement all the features of Google Talk except the voice talk. And all dialogs or layouts are copied from Google Talk, as I thought that Google Talk is excellent.

Architecture

Jabber Server (talk.google.com) –> XMPP –> Tomcat Server (Smack) –> mod_jk Connector –> Apache HTTP Server –> Browser Client

Implementation

Java2Script’ Simple RPC and Simple Pipe were used in the Java2Script Google Talk. Simple RPC serializes requests from browser to server, and server will parse them and send out related XMPP requests. All packets received from Jabber server are piped through Simple Pipe to the browser. The Simple Pipe just serializes XMPP packets into SimpleSerializable instances, and sends out through the comet HTTP connection.

That is to say, Simple RPC is OutputStream and Simple Pipe is InputStream in Java’s terms. And all data are serialized or deserialized by SimpleSerializable.

Optimization

JavaScript and DOM manipulation is very slow actually. And loading bundles of *.js from server to browser also requires a very long waiting. In order to improve the performances, lazy loading technologies are applied.

First, lazy loading those *.js related to the UI until the UI is required. For example, chatting dialog related classes’ *.js only be loaded when user open a chatting dialog or a message is received. This principles are also applied to settings dialogs, inviting friends dialogs and others. To lazy loading *.js, AClass or ASWTClass is introduced in Java2Script. It will load classes only when needed. The usage of A/SWT/Class is as following:

ASWTClass.shellLoad ("org.java2script.....", new ARunnable () {
public void run() {
// begin to later action.
});

Second, some part of codes are executed lazily. For example, create menus may require a lot of CPU times for browser. So only before the menus are to be shown do the menus are being created. In such a way, only what you see on the UI is created. Or they won’t be created by default.

Third, virtual list is used to avoid large friends list updating. For example, if there are more than 200 friends on one’s Google Talk friends list and concrete SWT widgets are created according to each friends, there will be 200 widgets being created. And it will freeze the whole browser UI. And when the dialogs are resized, re-layout these hundreds of widgets may also freeze browser. To avoid such freezing, virtual list is introduced. The virtual list is that only visible list item are created. Those invisible items are never created. In such a way, 500+ friends are supported.

Posted in Demo, SWT | 13 Comments