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

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:

SimplePipeRequest.switchToQueryMode(250);

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

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 ( http://jsc.sourceforge.net/ ), and Java to ActionScript ( http://osflash.org/j2as )

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

Here is the test script:

javascript:alert (0x1ffffffffffffe);
javascript:alert (0x1fffffffffffff);
javascript:alert (0x20000000000000);
javascript:alert (0x20000000000001);

You can see that the latter two numbers are same number in JavaScript!

Conclusion

The safe number range for integer is "-0x1fffffffffffff - 0x1fffffffffffff" (53bit). Therefore, in Java to JavaScript world, conversion of Java's long number to JavaScript's Number may result in incorrect calculations.

Basic Knowledge

Each HTTP connection is forked by browser. And one HTTP connection may serve multiple sessions in HTTP 1.1 but server only one session in HTTP 1.0. There is no time limit or data transfer limit on each HTTP connection. This is basic knowledge of HTTP connections.

An HTML web page, may contains lots of resources, images, style sheets or JavaScript files, and each resources requires an HTTP session. And according technologies called AJAX, browser can load resources at any specific time.

What is Simple Pipe?

Simple Pipe is a kind of data transformation from server to browser. Once browser open up an HTTP connection to the server, the server keep the connection open. And whenever the server get data, it will flush data through the HTTP connection to browser. The data transfered through the connection is serialized and deserialized in SimpleSerializable format.

How to Setup a Simple Pipe?

Simple Pipe is currently designed for Java language. There is a class named "com.java2script.ajax.pipe.SimplePipeRequest" with a static method named "pipeRequest" which accept a parameter in type of "com.java2script.ajax.pipe.SimplePipeRunnable". The SimplePipeRunnable is will accept parameters from browser side, and then be passed to server side (Tomcat or other Servlet containers), and its action will be executed. In most cases, an other-type connection is created, and listeners are added to the connections for up-coming events. And the connection will be registered with a generated pipe key. And the pipe key will be sent back to browser side. Browser side will create another connection to the server with the given pipe key. Server will check the pipe key, and hold the HTTP connection, and flush any data from previous registered connection to browser side in format of SimpleSerializable. Browser will use IFRAME to accept the data, and return back to object instances. In keeping the HTTP connection, browser will send a notifying signal (HTTP connection) to server to make sure that browser is keeping the connection live. If browser likes to close the pipe, it will send another Simple RPC call the server to notify server that pipe should be closed. If it happens that browser exit without notifying closing pipe, server will close the pipe in a minute or so, as there is no such signals for the pipe to be kept alive.

As Simple Pipe is a subset of Java2Script library API, Simple Pipe may only be used in Java language. But after being converted to JavaScript by Java2Script compiler, Simple Pipe technology can be used in JavaScript language. And JavaScript demo of Google Talk is an example of Simple Pipe.

Code Snippets

SimplePipeSWTRequest#swtPipe usage:

SimplePipeSWTRequest.swtPipe(new LoginRunnable() {

@Override
public void ajaxIn() {
username = userNameText.getText().trim();
password = passwordText.getText();
}

@Override
public void ajaxOut() {
if (failed) {
MessageBox messageBox = new MessageBox(MainWindow.this, SWT.ICON_ERROR);
// notify error
return;
}
setData("ConnectionKey", key);
setData("PipeKey", pipeKey);
// continue to login
}

@Override
public void ajaxFail() {
MessageBox messageBox = new MessageBox(MainWindow.this, SWT.ICON_ERROR);
// .. notify errors
}

public void deal(PresenceSerializable ps) {
// Data received from pipe! To update presence status
}

@Override
public void deal(final MessageSerializable ms) {
// Data received from pipe! To popup chatting dialog...
}

@Override
public void deal(RosterSerializable rs) {
// Data received from pipe! To update roster entries...
}

});


LoginRunnable

public class LoginRunnable extends SimplePipeRunnable {

public static class PresenceSerializable extends SimpleSerializable {
public String name;
public String email;
public String status;
public String type;
public String mode;
}

public static class MessageSerializable extends SimpleSerializable {
public String from;
public String body;
public String to;
}

public static class RosterSerializable extends SimpleSerializable {
public String from;
}

public String username;

public String password;

public String host;

public int port;

public String service;

public String key;

public boolean failed;

@Override
public String getHttpURL() {
return TalkRunnble.TALK_URL_BASE + "simplerpc";
}

@Override
public String getPipeURL() {
return TalkRunnble.TALK_URL_BASE + "simplepipe";
}

/**
* TODO: {@link #pipeSetup()} should be ignored by Java2Script compiler
* by default.
* @j2sIgnore
*/
@Override
public void pipeSetup() {
failed = false;
JabberHelper instance = JabberHelper.getInstance();
key = instance.login(username, password, host, port, service);
if (key == null) {
failed = true;
return;
}
new Thread(new Runnable() {

public void run() {
while (true) {
try {
Thread.sleep(30000);
} catch (InterruptedException e) {
//e.printStackTrace();
}
if (!isPipeLive()) {
pipeDestroy();
break;
}
}
}

}, "Jabber Connection Monitor").start();

XMPPConnection conn = instance.getConnectionByKey(key);

Presence presence = new Presence(Presence.Type.available);
conn.sendPacket(presence);

//XMPPConnection conn = JabberHelper.getInstance().getConnectionByKey(key);
conn.addPacketListener(new PacketListener() {

public void processPacket(Packet packet) {
pipeThrough(packet);
}

}, null);
}

/**
* @j2sIgnore
*/
@Override
public boolean isPipeLive() {
JabberHelper instance = JabberHelper.getInstance();
XMPPConnection conn = instance.getConnectionByKey(key);
return super.isPipeLive() && conn != null && conn.isConnected()
&& !instance.isConnectionLost(key);
}

/**
* @j2sIgnore
*/
@Override
public void pipeDestroy() {
JabberHelper instance = JabberHelper.getInstance();
instance.logout(key); // try to logout
}

/**
* @j2sIgnore
*/
@Override
public void keepPipeLive() {
JabberHelper instance = JabberHelper.getInstance();
instance.update(key);
}

/**
* TODO: {@link #through(Object...)} should be ignored by Java2Script
* compiler by default.
* @j2sIgnore
*/
public SimpleSerializable[] through(Object... args) {
if (args != null && args.length > 0) {
Packet packet = (Packet) args[0];
SimpleSerializable[] ss = new SimpleSerializable[1];
if (packet instanceof Presence) {
Presence presence = (Presence) packet;
PresenceSerializable ps = new PresenceSerializable();
ps.email = presence.getFrom();
Mode mode = presence.getMode();
ps.mode = mode == null ? null : mode.name();
Type type = presence.getType();
ps.type = type == null ? null : type.name();
ps.status = presence.getStatus();
ss[0] = ps;
return ss;
} else if (packet instanceof Message) {
Message message = (Message) packet;
MessageSerializable ms = new MessageSerializable();
ms.from = message.getFrom();
ms.body = message.getBody();
ms.to = message.getTo();
ss[0] = ms;
return ss;
} else if (packet instanceof RosterPacket) {
RosterPacket roster = (RosterPacket) packet;
RosterSerializable rs = new RosterSerializable();
rs.from = roster.getFrom();
roster.getType();
ss[0] = rs;
return ss;
}
}
return null;
}

public void deal(PresenceSerializable ps) {
// To be override
}

public void deal(MessageSerializable ms) {
// To be override
}

public void deal(RosterSerializable rs) {
// To be override
}

}


SimplePipeRunnable

public abstract class SimplePipeRunnable extends SimpleRPCRunnable {

/**
* Pipe's id
*/
public String pipeKey;

private boolean pipeAlive;

private SimplePipeHelper.IPipeThrough helper;

/**
*
* @param helper
* @j2sIgnore
*/
void setPipeHelper(SimplePipeHelper.IPipeThrough helper) {
this.helper = helper;
}

public String getPipeURL() {
return "simplepipe"; // url is relative to the servlet!
}

public String getPipeMethod() {
return "GET";
}

@Override
public void ajaxRun() {
pipeKey = SimplePipeHelper.registerPipe(this);
if (pipeKey != null) {
pipeSetup();
pipeAlive = true;
} else { // failed!
pipeAlive = false;
}
}

/**
* Listening on given events and pipe events from Simple RPC to client.
*/
public abstract void pipeSetup();

/**
* Destroy the pipe and remove listeners.
* After pipe is destroyed, {@link #isPipeLive()} must be false
*/
public abstract void pipeDestroy();

/**
* Return whether the pipe is still live or not.
* @return pipe is live or not.
*/
public boolean isPipeLive() {
return pipeAlive;
}

/**
* Notify that the pipe is still alive.
*/
public void keepPipeLive() {
// to be override
}

/**
* Update pipe's live status.
*
* @param live if live is true, just notify the pipe is still alive. if live is false
* and {@link #isPipeLive()} is true, {@link #pipeDestroy()} will be called.
*/
protected void updateStatus(boolean live) {
if (live) {
keepPipeLive();
pipeAlive = true;
} else if (isPipeLive()) {
pipeDestroy();
pipeAlive = false;
}
}

/**
* Convert input objects into SimpleSerializable objects.
*
* @param args
* @return SimpleSerializable objects to be sent through the pipe.
*/
public abstract SimpleSerializable[] through(Object ... args);

public void deal(SimpleSerializable ss) {
try {
Class<? extends SimpleSerializable> clazz = ss.getClass();
if ("net.sf.j2s.ajax.SimpleSerializable".equals(clazz.getName())) {
System.out.println("Default!");
}
Method method = null;

Class<?> clzz = getClass();
String clazzName = clzz.getName();
int idx = -1;
while ((idx = clazzName.lastIndexOf('$')) != -1) {
if (clazzName.length() > idx + 1) {
char ch = clazzName.charAt(idx + 1);
if (ch < '0' && ch > '9') { // not a number
break; // inner class
}
}
clzz = clzz.getSuperclass();
if (clzz == null) {
break; // should never happen!
}
clazzName = clzz.getName();
}
if (clzz != null) {
method = clzz.getMethod("deal", clazz);
if (method != null) {
method.invoke(this, ss);
return;
}
}
} catch (Exception e) {
e.printStackTrace();
}
// default
System.out.println("Default!");
}

/**
* A method used to pipe a bundle of instances through.
*
* Attention: Only visible inside {@link #pipeSetup()}.
* @param args
* @j2sIgnore
*/
protected void pipeThrough(Object ... args) {
SimplePipeRunnable pipe = SimplePipeHelper.getPipe(pipeKey);
if (pipe == null) return;
SimpleSerializable[] objs = pipe.through(args);

if (objs == null || objs.length == 0) return;

if (pipe instanceof SimplePipeRunnable) {
SimplePipeRunnable pipeRunnable = (SimplePipeRunnable) pipe;
if (pipeRunnable.helper != null) {
pipeRunnable.helper.helpThrough(pipe, objs);
return;
}
}
for (int i = 0; i < objs.length; i++) {
pipe.deal(objs[i]);
}
}

}


Here are some points:

1. Loading JavaScript file *.js by <script> tag may fail without acknowledge by the following JavaScript, which may result in a total page error;
2. Loading CSS style file *.css by <link> tag may fail, which results in ugly page layout;
3. Loading images by <img> tag may fail, which may confuse users;
4. ...

The above scenarios do not occurs often in development period. Because you may using local HTTP server to serve resources, or you may have high bandwidth with slow latency. But if you deploy your applications to server, your server may be busy all the time to serve resources, and will fail to serve some resources at some uncertain time. And people may report such bugs if they are in beta tests, but people may lose their deals or money if such failures happen in real online.

So, QoS is required.

How to make sure the RIA's qualities? First, make sure that such HTTP timeouts or failures does not interrupt normal business logics. To do so, try reload resources if such failures are detected. It would be easy to reload *.js file by <script> tag, or other resources by other tags. In order to detect failures, you may have your own loader. This is the reason why there is ClassLoader in Java2Script. To detect failures is also easy. Just hook the onerror or onreadystatechange event of loading JavaScript. Or you can setup a thread looping to check whether a *.css or an image is loaded or not.

There are other QoS aspects. Stay tuned for more coming discussions.

First, you can compress your JavaScript files before deploying them. Common compressors may cut 50% off of file size for normal JavaScript. That is to say, if your packed *.js is about 100k, the compressed *.js may be 50k. The compressed *.js may take about 100ms to decompress, but it when comparing to 50k over 1Mb/s bandwidth ( 50k * 8 / 1M = 0.4 s = 400ms). It worths such compressing. Usually bandwidth is not quite good as 1Mb/s, it will much better for compressed JavaScript.

Some well-known JavaScript compressors are Dean Edwards' Packer and Shrink Safe by Alex at Dojo. You may find some other compressors, like Java2Script's LZ77 JavaScript Compressor.

Second, you can send out your JavaScript files as gzip-encoded by Apache server. For most of modern browsers, gzip-encoding can be accepted. So you should configure your Apache server to do so especially when your JavaScript is over 200k. In common cases, gzip-encoding saves over 75% of JavaScript bandwidth. That is to say, 200k JavaScript only takes up 50k transmission. What a great improvement.

But please pay attention to some defects of JavaScript gzip-encoding for some browsers, like IE. Well, Internet Explorer takes up 80%+ of browser shares. You must not ignore IE's defects on dealing JavaScript gzip-encoding. As IE6.0 SP2 and IE7+ already fixed this bug. You should support these two browsers, as it may get more and more market share.

So when configure .htaccess file for Apache httpd server, you should ignore those buggy IE browser or non-supported browsers. Here is my .htaccess file:

<IfModule mod_deflate.c>
# Netscape 4.x or IE 5.5/6.0
BrowserMatch ^Mozilla/4 no-gzip
# IE 5.5 and IE 6.0 have bugs! Ignore them until IE 7.0+
BrowserMatch \bMSIE\s7 !no-gzip
# IE 6.0 after SP2 has no gzip bugs!
BrowserMatch \bMSIE.*SV !no-gzip
# Sometimes Opera pretends to be IE with "Mozila/4.0"
BrowserMatch \bOpera !no-gzip
AddOutputFilterByType DEFLATE text/css text/javascript application/x-javascript
Header append Vary User-Agent
</IfModule>

For more information about this gzip-encoding configuration, please google "IE gzip javascript encoding" or read Joshua Eichorn's blog article "Compressing JavaScript and CSS".

Third, this is still about gzip-encoding. But this method tries to include JavaScript in HTML sources directly. As IE has no bugs on decoding gzip-encoded HTML files, compress JavaScript in this way will suite for most IE6 users. As far as I know, GWT uses this way to send out their JavaScript. But loading those HTML files in an embed IFRAME may make the whole architecture a little strange or hard to understand. Few people uses this method.

Maybe there are some other ways to compress and deploy JavaScript. Please let me know or discuss with me if you have a new one.