Monthly Archives: September 2007

Performance Matters or Not

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

Performance of Comet and Simple Pipe

About one and a half months ago, I introduced Java2Script Simple Pipe, another Comet implementation. At that time, I knew there were lots of performance issues on such Comet technology. Because at that time I were busy and it was not a urgent deal for me, I didn’t write test codes to test out the performances at that moment.

Only recently, I took some tests on performance issues. And the results said Simple Pipe’s Comet implementation performs really bad!

Opening 10 Comet connections using Simple Pipe does not affect the whole server. But when I opened 20 Comet connections, the CPU usage is up to 100% quickly! It’s not a problem of the application logics. It is a matter of Comet connection.

Java2Script Simple Pipe supports switching pipe mode into query mode. It is very easy, just call a static method:


After switching to query mode for the pipe, I can open up to 100+ connections to the server to receive stream data back to browser. The peak of CPU usage is about 60% ~ 70%. The average CPU usage may be about 20%-30%. It is an acceptable technology with such performances under the pressure tests.

( I did not test those server with special Comet optimizations. I just tested Simple Pipe on Apache Tomcat 5.5. Maybe those Comet optimized should have a better results. )

Posted in Architecture, Articles, Comet, JavaScript | 4 Comments

Java != JavaScript

The cry-out of “Java != JavaScript” is not a new expression. I learned it in year 2001 when I started learning JavaScript.

But as “Java2Script” project, it links “Java” and “JavaScript” together by a Java to JavaScript compiler. It is unavoidable to explain these two languages in Java2Script manner before making senses.

“Java” is a word for “OO” (Object Oriented) concept in the eyes of Java2Script. C++ is considered not a pure OO language, but C# may be. And there are other OO languages. But the well-known one should be Java. Java2Script just takes Java as a great OOAD tool (language tool) to analyze, design and implement desktop applications or rich client platform (RCP).

Naming ECMAScript as JavaScript is big mistakes for early Netscape developer. But we already accepted it. Even though lots of JavaScript syntaxes are similar to Java, it does not matter that JavaScript is a different language. And ActionScript, which is used in Flash, is another script language which is based on ECMAScript. It seems that few cares about comparison between Java and ActionScript. Whatever language is, Java2Script developers need tools to design rich internet applications (RIA).

On fields of language conversion, you may already know that GWT is also a Java to JavaScript compiler that links together these two languages. And I also know that there are other languages to JavaScript compilers. For example, C# to JavaScript compiler ( ), and Java to ActionScript ( )

… // more needs to to be explained

In some simple words, “Java” and “JavaScript” is not two languages but two tools (or tool sets) in the opinions of Java2Script. By Java2Script compiler, we can use these two tools to develop once but get both RCP and RIA at the same time. That is the key advantage of Java2Script.

We do not care what languages are used. We know we use OO concepts to design things and get what we want by using the existed tools.

Posted in GWT, Java, JavaScript | 7 Comments