Category Archives: JavaScript

Loading J2S SWT Application Inside Existed HTML Pages

See the home page for inline demo or visit http://j2s.sourceforge.net/j2s-demo.js for more details.

It seemed that sourceforge.net was very slow for my network location. I had to refresh one or two times to get all *.js correctly loaded. And it seemed that waiting for every *.js is a very boring experience.
Enjoy the inline demo.

Posted in Java2Script News, JavaScript | Leave a comment

A Link An Application

For example:

javascript:(function(){var d=document,b=%22http://java2script.ognize.com/1.0.0-m3/%22,t=%22onreadystatechange%22,x=d.createElement(%22SCRIPT%22),f=function(){var s=this.readyState;if(s==null||s==%22loaded%22||s==%22complete%22){var c=%22org.eclipse.swt.examples.controlexample.ControlExample%22;$CL1(b);$CL2(b+%22../control-examples/%22);$CL3(c,function(){eval(c+%22.main([]);%22);});}};x.src=b+%22j2slib.js%22;(typeof x[t]==%22undefined%22)?x.onload=f:x[t]=f;d.getElementsByTagName(%22HEAD%22)[0].appendChild(x);return;})();

will link to an SWT control examples. We can also call this as “A Link An Application”(ALAA).

OK, let’s see what is going on. Now load SWT control examples from java2script.ognize.com (test site only, may be slow and unstable, enjoy it) into this page.

Or, you can copy the link of SWT control examples, and then visit a new HTML page, for example, visit Google, and then paste the link to the location, and then go. You should find the SWT control examples will be loaded inside Google’s page. All you dealing with is just a link! But you alreay get an application everywhere inside your browser.
Users can also bookmark the “javascript:…” links. To bookmark a “javascript:…” link, you should first bookmark a normal HTML page, and then copy the “javascript:…” link location and paste as URL location in the bookmark’s properties dialog. Some browsers (e.g. Opera) will let you change URL when you’re bookmarking without a later modification of URL.
And whenever users want to load the application, users can click the bookmark, which will bring up the application in users’ currently visiting HTML page. For example, if you have already bookmarked the above SWT control examples application as “javascript:…” link. And if you are visiting visit W3C, and you can click the bookmark, and the application will be loaded without leaving the W3C pages.

That is the mean of “A link An Application”. A “javascript:…” link is an application, which may be hosted inside any given HTML pages. And the “javascript:…” link would be a very useful and complicated application besides those simple “javascript:history.go (-1);” or “javascript:alert(document.lastModified);”. So there are chances that you can deliver your useful and complicated web applications via generated “javascript:…” links into any other HTML paes or other web applications.

You can also considered the “javascript:…” link as plugin extensions to the browsers that needs no installations (Only bookmarking). There are plugins for Firefox or IE. Most of those plugins need installations and may also need manually updates or uninstallations. But the “javascript:…” links is free of those deployment instructions. All the application is just a “javascript:…” link. That is enough simple.

A link is an application. An application is a link.

Posted in A Link An Application, ALAA, Java, Java2Script News, JavaScript, Sharing, SWT | Comments Off on A Link An Application

Position is Everything

Currently, J2S’ SWT widgets are on the way of being pixel-precise. And some certain pain things come up:

1. Different browsers

IE (IE6/5.5/5.0 and IE7, too many, I mainly work on IE6), Firefox (Different versions will render position in some slight differences), and Opera (Just check out to see if there are ugly looks in Opera 8+, no pixel-precise supports)

2. Native SWT implementation v.s. browser implementation

I have to debug into the native SWT implementation, and look for the native positions of different widgets, and then debug into the JavaScript’s SWT implementation to see if the positions match. And thanks a little, the JavaScript is actually the Java codes, so I can do refactors or navigate between codes easily by Eclipse. And J2S’ inner console also helps a lot for printing out those necessary values. The procedures is something like developing C codes for Java to call through JNI.

3. CSS layout v.s. JavaScript layout

The SWT implementation requires both CSS layout and JavaScript layout. CSS is powerful, but it’s also too complicated and it has its pitfalls on dynamical layout and it can not tell complicate rules. JavaScript’s layout is free to anything but requires extra CPU times on calculating positions. And the position is mixed up with all kinds of CSS styles, for example, different “font-size”s, different “border”s, different “margin”s, …

4. What about supporting different CSS templates

…en, big thing, until almost 90%+ SWT APIs are implemented. …

Actually J2S’ SWT will hide the above pains from SWT developers.

SWT developers or web application developers only need to develop the native SWT applications and then enable Java2Script compiler for the Eclipse project. Then the compiler will convert Java things into JavaScript. After packing the generated resources (image and css and javascript) up with the J2S SWT libraries. You will get your web applications. You won’t have the above pains, as those pains belong to J2S SWT team.
Here following is a testcase snapshot.

Native Win32 SWT window:
Native SWT Group and TabFolder

Converted J2S SWT window in IE6:

J2S' SWT Group and TabFolder

Posted in Java, JavaScript, Sharing | Leave a comment

GWT v.s. Java2Script SWT

Google has released Google Web Toolkit (GWT), ….

Aha, google is doing the same thing as me: Java2Script Pacemaker.

The same pattern: Java-to-JavaScript compiler, provide general java.lang.* and java.util.*, and an extra UI widget library.
In Google Web Toolkit, the UI widgets is GWT, while in Java2Script Pacemaker, it is Eclipse’s Standard Widget Toolkit (SWT).It seems GWT is a much lighter library than SWT. Currently Java2Script’s SWT is growing to about 400k of *.js files for about 80%+ API support. After compression the file size is about 250k. 250k v.s. 100k. Hoho it seems J2S’ SWT need more works.

Some more comparisions of GWT and Java2Script:

  • Now GWT has no IDEs support but can be developed within Eclipse, while Java2Script Pacemaker is a plugin extending Eclipse JDT plugin, so its UI is Eclipse SDK. Java2Script is not a standalone application.
  • GWT’s UI may not be reused on desktop, while J2S’ SWT is another implementation of SWT’s API. That is to say, it’s SWT on Browser besides SWT on Win32, SWT on GTK, SWT on PPC, … So SWT applications developing for desktop can be reused or directly exported to web browser.
  • GWT’s UI is for web, and SWT is for both deskop and web. And J2S’ SWT looks more similar to desktop application.
  • GWT has been integrated with Java EE, while Java2Script is still not (Planned but not yet implemented).
  • For license, GWT is on its own license, J2S is licensed under the much well-known Eclipse Public License 1.0.
  • About releases, GWT is now 1.0.20, while Java2Script is before 1.0.0 M2 besides its ealier 0.1.0 to 0.5.0 and 1.0.0 M1.

Aha, Java2Script Pacemaker welcomes you.

/js (*_*)

Posted in Java, Java2Script News, JavaScript, Uncategorized | 11 Comments

Will JavaScript 2 be the Future of the Web?

In “Brendan Eich: JavaScript 2 and the Future of the Web”, it says:

We were lucky enough to have Brendan Eich, creator of JavaScript, give a keynote at The Ajax Experience.

We have placed the presentation online so everyone can read up on some of the thoughts and discussion on JavaScript 2 and more.

Here we got to hear from the mouth of someone deep into the ECMA process about what we are going to see in JavaScript 2 and importantly why:

So I begin to think that: will the time interval 2006-2010 (4 years) be somewhat too long?

Are there useful tools to speed migration?
* A JS2 to JS offline translator, for example
* Write your web app using JS2 exclusively
* Run the translator over all of your JS2 code
* Serve the translated files to old browsers

The project Java2Script, which I am working on, is providing a Java to JavaScript convertor. To develop web applications, it recommends the way of writing JavaScript in Java Syntax (Actually writing Java totally by IDE and then converting Java to JavaScript).
But some comments sound

“Don’t turn it into Java!�?

These comments do bewilder me and make me think further.
From the above Brendan’s presentation, we can see a lot of syntax improvements, which are popular in Java, C++, Python or Ruby. Maybe we could call them syntax sugars. Sugars won’t be enough. Robust IDEs are needed to help writing or managing those scripts.
So I am thinking: Will JavaScript 2 be on a way of being another language if it is not adopted widely and quickly by Browsers and IDEs while JavaScript 1 keeps being popular? If such things happen, a maybe JS2 to JS converter will always be used. Then JavaScript 2 will be similar to other languages like Java, Python, as those languages also can be converted into JavaScript by convertors. Then a question: why wait 2~4 years or longer for JavaScript 2 syntax sugars? Why not having the syntax sugars of Python, Ruby, Java or C++ right now by convertors?

PS: It seems that I am being affected by Java2Script too deep to make such comments on JavaScript 2.

Posted in Java, JavaScript | Comments Off on Will JavaScript 2 be the Future of the Web?

Early J2S’ Eclipse JFace Dialog

I spent sometimes on converting Eclipse’ JFace codes, and got something like TitleAreaDialog:

Early J2S JFace

But it took about 2+s(4s for IE6 on my machine) to do such layout (this time does not include the 1+s loading the *.js). It was just an experiment for things. And J2S JFace won’t be released in J2S 1.0.0.

Posted in Java2Script News, JavaScript, Sharing, User Experience | Comments Off on Early J2S’ Eclipse JFace Dialog

Object Oriented Programming in JavaScript by Java2Script

Summary

It’s well-known that JavaScript is a prototype based or object based scripting language not a complete Object Oriented Programming (OOP) language as Java, which is a well-known and most-succeeded OOP language. As AJAX applications boosting, lots of JavaScript inheritance systems are developing to make codes more readable, more manageable and more developer-friendly. However, polymorphism and super method calling, which are two most important features for OOP, are not implemented or not fully implemented. In this article, a new library will be introduced for JavaScript to simulate a complete Object Oriented Programming. And a new Eclipse JDT plugin, named “Java2Script Pacemaker”, will also be introduced to help developers in converting Java codes into Object Oriented JavaScript codes directly.

For more, please read the OOP in JavaScript by J2S(Draft) .

Posted in Java, JavaScript | 2 Comments

J2S JavaScript Inheritance Core Released

News: J2S Clazz released (March 10, 2006)
About J2S Clazz:
J2S Clazz is the core JavaScript file for the Java style classical inheritance system. It’s the fundamental part of Java2Script Pacemaker.

Features:

  • It’s small, less than 8K.
  • It provides full support of Object Oriented Programming, including the most important features polymorphism, super calling and constructors.
  • It does not break the existed protype inheritance. And it can be integrate with other existed libraries.

Download:
J2S Clazz 0.6.0

Articles:
OOP in JavaScript by J2S(Draft)

Posted in Java2Script News, JavaScript | 2 Comments

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
http://idwhiz.vicp.net/examples/net.sf.j2s.examples.RSSReader.html.
May need patience for the loading…

Posted in Java, Java2Script News, JavaScript | 1 Comment

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 | Leave a comment