Today, I came up with 280 Slides, a web presentation design editor. I was shocked by its pretty looking Mac-like UI at the first glance.

From an interview to 280 Sliders developer, I learned to know that Cappuccino is the framework behind the product. And Objective-J language is introduced so they can port Apple’s Cocoa framework. Cocoa is a framework based on Apple’s own language Objective-C. In fact, 280 Slides’ UI looks like Apple’s Keynotes. And the 280 Sliders’ developers are former Apple developers. Cappuccino parses Objective-J files, which are with file extension .j, convert to JavaScript codes and executes them on the fly.

So, another cross compiler, Objective-C to JavaScript. It is quite worthy for further digging.

And digging into sources, I find that it uses lots of images to make up the whole UI, includes button, scrollbar, window borders and other components. And besides *.j and *.js files, there are some *.plist and *.sj files. *.sj use the same syntax as normal JavaScript. But from the sources, I guess they are compiled and mixed from *.j. Besides the core Objective-J.js, AppKit.sj, Foundation.sj and SlideKit.sj are three important files.

And it is great to hear the news that Cappuccino and Objective-J will be open-sourced at http://objective-j.org/ in the near future.

Today, I came up with the idea of “Orto: Java in JavaScript“. Well, it is not “Java to JavaScript”, it is “Java in JavaScript”. It is said that java.lang.Thread is supported. But as there is no downloads available, and it is not open source, so I could not test it.

Supporting Thread programming in JavaScript would be cool. Once I spent some time trying to figure out how to support Thread in Java2Script project, but I failed. But I managed to program execute codes asynchronously by using SWT’s Display#timerExec(int, Runnable) or Display#asyncExec(Runnable) instead. So even though I can not use Thread#sleep, I still can do lots of thread things.

And Orto seems to be in a different way to support Thread, the codes it generated look like these:

case 117:orto246[orto247-2]={high:(~orto246[orto247-2].high)
&0xffffffff,low:(~orto246[orto247-2].low+1)&0xffffffff};
if(orto246[orto247-2].low==0){orto246[orto247-2].high++;
orto246[orto247-2].high&=0xffffffff;
orto246[orto247-2].low=0;
}break;

Compiling to Java code into byte-code like script, and loading and running these scripts in “JVM” should be a way to support all Java things. In my opinions, all locks and threads are re-implemented. Performance should be a problem. I know that there is another project called XML11, which is also trying to compile Java codes into JavaScript byte-code.

And recently, I also noticed that there was a debate about GWT Ext or Ext GWT. You may already know that GWT is about compiling Java to JavaScript and Ext JS is a HTML/CSS+JavaScript based UI library. It is interesting to see people combine these two technologies together. And it is more interesting that putting GWT before Ext JS and putting Ext JS before GWT is two different things. You may want ot read Didier Girard’s discussion for a clear idea.

About 2 years ago, when I started Java2Script project, I had to think about its programming model. At that time, people began to wrap existed JavaScript library in Java way. I called it “JavaScript for Java (JavaScript4Java)”, which is quite different from my “Java to JavaScript (Java2Script)”. So “2″ and “4″ is totally different, right?

In fact, I do know that Java and JavaScript are two different language. The reason that I chose Java as the source and JavaScript as the target is that Java is most beautiful and most used language while JavaScript is a world wide supported language. And I am familiar and love Java language. So I created Java2Script. I do believe that C#-to-JavaScript, Ruby-to-JavaScript or Other-to-JavaScript is not a big deal for me. But I may not have energy to make a similar compiler.

Java and JavaScript may be hotter and hotter. Good to see that more and more people is linking Java and JavaScript together.

It’s amazing to see that Java2Script’s Google Talk get run on Opera Mini 4 inside a mobile phone.

Here is Opera Mini 4’s simulator for you to test its CSS/JavaScript/AJAX compatibilities:
http://www.operamini.com/beta/simulator/

Here are screenshots:

Zoom in to get a clear look:

Login and connect:

Now we are in:

Zoom in to get a clear look on friend list:

But Java2Script Gtalk does not get run as totally correct. It fails to maintain normal connection back to Gtalk proxy server. So after a few seconds, the proxy server closes the connection. Maybe Java2Script Gtalk may fix this problem later. And also I think Opera Mini team may improve its AJAX supports in the near future so nothing need to be modified.

As Java2Script’s library size is getting huger and huger, loading *.js is a critical job for Java2Script. And I decide to output compressed *.js to save loading bandwidth.

In httpd.conf or .htaccess file, add the following:

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

You can read more about mod_deflate document.

In my experiments, I found that IE 6.0 had a strange bug in loading compressed *.js, so IE 6.0 was fed with huge raw *.js.

In normal bandwidth connection with Firefox 2.0, it takes about 16 seconds for the first time loading and running Java2Script application, and it takes about 6 seconds for later running (Cached *.js are applied). From the log file, there are about 20~30 *.js/*.css/*.png/*.gif hits, which counts up to about 150k. Thanks for the mod_deflate of Apache HTTPD Server. It saves a lot of bandwidth on those maybe 600k+ *.js files. And I considered such Java2Script application loading or running acceptable.

By the way, long waited Java2Script Milestone 5 release is coming. Lots of new features are added.

Update: For more details, please also read article “Compressing and Deploying JavaScript“.

The long waited 1.0.0 M5 Release (Once supposed to be 1.0.0 Release Candidate) finally came.
To download and install Java2Script M5, please check
http://j2s.sourceforge.net/download.html
and
http://sourceforge.net/project/showfiles.php?group_id=155436
Regard,
Zhou Renjian
===============
1.0.0 M5 (March 16, 2007)
New and Noteworthy
==================
Java2Script Core
—————-
1. Use Apache Harmony JRE sources instead.
2. Improved ClassLoader now supports multiple threads loading from multiple sites.
3. Lots of ClassLoader bugs are fixed to make sure *.js or *.css are correctly loaded or applied.
4. ClassLoader’s class loading is notified in a half-transparent messagebar.
5. Library *.js can be loaded from Firefox Add-on.
6. Java2Script inner console’s color is now black on white.
7. Java2Script related projects can be created by wizards.
8. Java2Script compiler is refactored a little.
9. More *.js optimized configuration for Apache HTTPD server, including gzip encoding.
Java2Script SWT
—————
1. Window manager is introduced.
2. Shell’s maximizing and minimizing are improved.
3. Increasing or decreasing font size in Firefox is supported.
4. Widgets are improved.
5. SWT lazy loading is built inside.
Java2Script AJAX
—————-
1. Simple RPC protocol is modified
2. Simple RPC now supports Cross Site Script.
Java2Script Example
——————-
1. Java2Script version of Google Talk ( http://demo.java2script.org/gtalk/ )

PATCH UPDATE:

If you download or install Java2Script 1.0.0 M5 after March 21, 2007, you should ignore this patch.

If you download or install Java2Script 1.0.0 M5 before March 21, 2007, you may need to make a patch following the instructions:

Because of a not tested bug that the packed Common.z.js in plugins/net.sf.j2s.lib_1.0.0(.v510/.v520)/j2slib/org/eclipse/swt/widgets/ does not contain TabItem.js, which will result in errors of “$wt.widgets.TabItem is not a constructor” when loading Java2Script SWT application that uses TabFolder widget.

To fix up the problem, please download the patch, and unzip it, replace the old Common.z.js with the new Common.z.js.

If you also download the sources, please replace net.sf.j2s.lib/build/build.xml with the new build.xml.

If you have already installed Java2Script Firefox Add-on, please replace **Path to your Firefox profiles**/extensions/{d60b46a9-bfe3-4b22-8844-07089202e0e6}/chrome/content/
java2script/1.0.0-m5/org/eclipse/swt/widgets/Common.z.js with the new one. In Windows, Common.z.js may be in **System Drive**:\Documents and Settings\**Your Login Name**\Application Data\Mozilla\Firefox\Profiles\**Unique String**\extensions\{d60b46a9-bfe3-4b22-8844-07089202e0e6}\chrome\content\
java2script\1.0.0-m5\org\eclipse\swt\widgets\.

I feel very sorry about the inconveniences.

March 21, 2007

Follow instructions of “setup Java2Script environment from Subversion repository“, and checkout branches 3.3 from https://j2s.svn.sourceforge.net/svnroot/j2s/branches/

Hope to hear your feedbacks.