Monthly Archives: February 2006

Java2Script 0.5.0 Released with Java’s AJAX

News: 0.5.0 (February 18, 2006)

New and Noteworthy
Java2Script Core

  • Fully implement keyword “final”.
  • Support transforming Java codes that use “org.w3c.dom.*” into JavaScript (See more in AJAX part)
  • Implement the arguments when running Java2Script inside Eclipse
  • Support all Eclipse 3.1.* by enhancing the org.eclipse.jdt.core_3.1.*.jar programmly

Java2Script SWT

  • More widgets supported: Group, Sash, SashForm, Scale, ProgressBar, StackLayout.

Java2Script AJAX

Download now:
J2S 0.5.0 for Eclipse 3.1.* (with all of plugins, sources, examples, tutorials) 2,287K

Posted in Java2Script News | 1 Comment

Simple RSS Reader by J2S SWT and AJAX

News: Feb 16, 2006
J2S provides two more tutorials:

Here, take a look at the RSS Reader
May need patience for the loading…

Posted in Java, Java2Script News, JavaScript | 4 Comments

About String in Firefox, IE and Opera

I mentioned the LZ77-JavaScript-Compressor early this month. And today I read Alex’s “another reason to use Dojo: dojo.string.Builder“, and modified a few lines of the codes so that it takes the advent of Firefox’s String.

But actually it do not work better as I expected. In firefox it originally takes about 3~3.5s to uncompress about 400k sources from 135k string. After modification, it takes about 2~2.5s. And the originally Array.join method takes about 5s in IE. And finally I test the modified method on Opera 8. I was astonished: it’s 0.7~1s, which is my expectation! But the original method takes about 3~3.5s in Opera!

That is to say, Opera’s “String += String” is about triple faster than Firefox and about 7x faster than the best way of IE!

Firefox v.s. IE v.s. Opera, and this round’s WINNER is Opera.

Posted in JavaScript | 2 Comments

User Experience Series: History, Now, Future

Someone said the pseudo SWT window inside browser is so different from the common browser application, which may cause a bad user experience. So I began to think about user experience. In fact, I thinking pseudo SWT window won’t have big effect on user experience, but something else are important on user experience. Here follows my opinions.

There are three aspects about user experience: History action, current status and future data.

User will always keep the history in his/her brain. And good UI interaction should always keep all possible history from the user. Don’t break or change the history. For example, browser has already implemented the navigation history. If your page switch to a new page, your page must can be backward-forward-compatiable. Once your page support editable, you should implement the undo-redo actions and keep the modified history.

User will understand the current status of the page. User knows whether the page is correct or incorrect status. If the page is in incorrect status, he/she will do something to correct them. You should never limit the user from actions that will leave things in incomplete status. Incomplete status must be kept. For example, application provide ways for user to input Java/C/C++ expression/statement, the expression/statement will always in incomplete or incorrect status until all codes written and reviewed.
User always want to do something, which is still incomplete. For example, user try to type in name “Josson Smith”. Once he/she type “Jos”, if the application is smart enough to provide the possible future options “Josson Smith”, “Joshua Clinton”, it will improve the user experience.

So sugguestions of improving user experience is

  • keep all possible actions from the user, and provide some ways for the user to move backward or forward.
  • keep the possible incomplete status until user finish it.
  • try to fetch data that is useful for the user, show them.
Posted in User Experience | 9 Comments

JavaScript Closure Performance Test

Closure is an important concept of language JavaScript. Using closure will give you freedom of writing JavaScript codes efficiently. But what about the extreme performance of JavaScript closure?

For example:

var count = 1000000;
var num = 0;
function withClosure () {
var i = 0;
while (i++ < count) num++; } function withoutClosure () { var count = 1000000; var i = 0; var num = 0; while (i++ < count) num++; } Which method will run much faster? Here is the sample test result of my computer: Firefox ======= with closure : 1141 without closure : 375 Internet Explorer ============= with closure : 969 without closure : 485 It seems that under extreme condition, accessing variable from different closure will have poor performance. So it's recommended that never access variable from different closure in those frequently-used or time-consuming functions. Appendix: window.alert = function (s) { document.body.appendChild (document.createTextNode (s)); document.body.appendChild (document.createElement ("BR")); }; function timing (label, action) { var d = new Date (); action (); alert (label + " : " + (new Date ().getTime () - d.getTime ())); } var count = 1000000; var num = 0; function withClosure () { var i = 0; while (i++ < count) num++; } function withoutClosure () { var count = 1000000; var i = 0; var num = 0; while (i++ < count) num++; } timing ("with closure", withClosure); timing ("without closure", withoutClosure);

Posted in JavaScript | 6 Comments

Asynchronous Programming

Just keep the comment back from Youngpup’s Managing complexity in asynchronous GUIs – Words
Comment URL:

I also thinking about asynchronous programming these days not only for JavaScript but also for Java.

These days, I dedicated in open source project Java2Script Pacemaker at It will provide tookit to transform existed Java codes into JavaScript codes, including the possible UI widgets (Eclipse’ SWT). But one problem must to be solved is blocking and threads. AJAX, the essential part is “A” which is asynchronous programming. But what about asynchronous programming is brought into the Java’s object-oriented programming?

Already, Java programmer can use system native semaphoro or thread to implement blocking. For example, Java programmer will open a dialog and wait for response result:

Dialog dialog = new Dialog(...);
int result =;
if (result == OK) {
String name = dialog.getUserName();

But in the asynchronous programming, it would be something like this:

final Dialog dialog = new Dialog(...);
dialog.register(new Runnable() {
public void run() {
int result =;
if (result == OK) {
String name = dialog.getUserName();
// return here!

Once the Java codes is asynchronous-oriented, I think the Java codes can be exported into JavaScript codes directly by Java2Script Pacemaker.

But in fact, asynchronous programming or refactoring existed synchronous programmed libraries into asynchronous-oriented libraries will require times.

Posted in Java, JavaScript | 325 Comments

LZ77-JS-Compressor: Another way of compressing JavaScript

June 6, 2007 updated: LZ77 JavaScript Compressor is rebuilt using Java2Script Simple RPC technology.

Sep 4, 2006 updated: Please read “LZ77 JavaScript Compressor Reloaded“.

In compressing JavaScript, I prefer to But the packer does not have a Java version. So some days ago I was thinking to write a similiar Java version of JavaScript packer, same as Dean’s packer.

But finally, a different JavaScript compressor came out. Its algorithm was based on the well-known LZ77, which is also the algorithm base of GZIP. Uncompressing of this method ran poor in Browser. It took about 2~4 seconds to uncompressing about 130k into 400k.

But when I integrate LZ77-JS-Compressor with Dean’s packer. It worked happily with about 4s+ lapse. In the practice, 400k JavaSource was zipped into 180k by Dean’s packer. And then 180k zipped JavaScript was compressed by my LZ77-JS-Compressor with result of about 100k of finaly scripts! It took about 1.5~2.5s uncompressed by my 1k uncompressor, and 0.5~1.5s unpacked with Dean’s packer, and finally 0.5~1.5s evaluating the script sources. Different browsers were performing differently in different periods.

Once the packer reaches the compressing ratio at about 33%. Now it comes out that 25% of compressing ratio! It saves about 80k more bytes from 180k sources. And now for 56K modemn it takes 100k * 8/56k + 3 ~ 19 seconds to load the whole pages. For those bandwidth it takes 1~4 seconds plus for the page! But infact, we always get our pages at poor speed.

Demo page with LZ77-JS-Compressor is here:

PS: The performance is worser than what I expect. For Firefox, it need about 4.5s to uncompress the script, which is acceptable. But for IE, it takes about 10s to initialize the script!

And each time, I go back or revisit the page, it requires the same times calculating and uncompressing!

OK, just take this as a way to uncompress text data.

Posted in JavaScript | Leave a comment

Java2Script 0.4.0 Released

New and Noteworthy
Java2Script Core
1. Make the Java2Script project more configurable by refining the Java2Script Builder page and contributing editor for *.j2s file.
2. Bugs fixed: Java2Script on Linux platform generates JavaScript files incorrectly; Java2Script compiles “char” type incompletely; and others
3. Eclipse 3.1.2 supported besides 3.1.1

Java2Script SWT
1. More widgets supported: Text, Label, Tree, Table, TabFolder, Composite, Button (TOGGLE, RADIO, CHECKBOX). For more information, please visit
2. J2S SWT application can be configured and run much easily inside the Eclipse
3. Fixed memory leak bug in IE

Java2Script and AJAX
1. Examples of integrating J2S SWT with prototype AJAX library are shown in, AJAX from Java perspective is still under designed.

Please visit Java2Script home page or download page for more details.

PS: I have spent about 2 painful hours, waiting patiently, to make this release! Because there was a national firewall blocking me from accessing (blocking only not *, I had to access sourceforge by socks proxy through HTTPS. The network speed is … Finally, I gained my patiences from that shameful Greate FireWall.

Posted in Java2Script News | Comments Off on Java2Script 0.4.0 Released

Bug of split() in IE?

var lines = “Hello\r\n\r\nJ2S\r\nWorld\r\n”.split (/\r\n|\r|\n/g);
alert (lines.length);

In both Mozilla/Firefox and Opera, it is 5. But in IE6, it is 3!

Is it bug of IE6? Does it exist in former IE or the future IE7?

Posted in JavaScript | 84 Comments