Google Web Toolkit - some experience now...

It was with relish that I embarked on putting the google web toolkit through it's paces. In fact, for the first time in long time, I coded for fun on the weekend. The recent addition of a laptop helped in this regard however...

For a long time I have wanted to build a simple database app to help out a local church. It's a simple app to manage a list of people, their particulars and other properties. Now I thought that would be an ideal test bed for the new google web toolkit - how cool would it be to make it a AJAX rich client app that runs in a browser. A familiar "link" would be all that is required. Because it will run in an intranet environment speed was not a consideration.

All in all, I was able to reach a fairly advanced stage, quite quickly. The API is very simple and easy to use. The "hosted" mode helps a lot. There were a couple of anomalies in the compilation of the javascript - you can't go wild with anonymous inner classes, the parser doesn't handle those very well, and there seems to be some conditions on your package names.

All in all, however, for an application of this nature, the google web toolkit is ideal.

I will have to do some work on the back end to get the data to persist, probably going to use flat files and an xml based serialization mechanism. It's very easy however to use stubs for those back end calls - funny how they're termed back end calls, whereas in actual fact they're simple request to an http server. With AJAX and DHTML the client is no longer dumb!

I had something else that I wanted to throw google web toolkit at (I call it "goowit" for short)...

Recently I built a Sudoku puzzle solver in java - complete with funky swing user interface and all - you enter the numbers, click go and it solves it. I was very keen to see if this would port to java script via gwt so that it can be deployed easily on the net. It took me a while to remove all the non gwt supported stuff - there were a lot of dependencies on java API classes not supported by gwt. I thought at one stage that it in fact would not work. In the end, it did, and I was very impressed.

So it was with great excitement that I finally got rid of all the "cannot import" messages on the hosted mode console - be aware that if an import fails it means that that the class has not been successfully translated, probably because it contains unsupported content. Once this was done, I entered my numbers and clicked go. In an instant it solved the puzzle.

Now for the final test, compile to javascript and see how it runs on the browser. This was where my heart sank, it was unacceptably slow. In fact, it probably would have taken about a day to solve one puzzle! The browser's "A script is taking too long" came up even before the first cell was picked!

Something which ran fine in hosted mode (java compiled mode) was far too slow in javascript mode. Now I'm not 100% sure exactly why - is it because the generated code is inefficient or just because job is too big for an interpreted language. I can't say. I think the rule of thumb here and it sounds obvious is to avoid doing heavy duty, complicated and long running processing with javascript. Not only because it may be slow but also because javascript is a single threaded environment and you need that one thread for keeping the gui snappy. Whilst a javascript process is running, the browser is totally non-responsive.

More exciting discoveries await...

Google Web Toolkit… a first look

When I was first exposed to the AJAX technology and how it works at the Sun Tech Days, I thought to myself, why then can't you code in java and get a tool which allows you to "press button for thick client", or "press button for thin client". It would have to be some kind of a cut down version of java because you wouldn't be able to do everything on a thin client than you can do on a thick client.

In a nutshell, this is what Google has done with their google toolkit. It is, like a friend first said to me, "a way to write AJAX applications with standard java code".

They have solved a lot of the problems and what they've come up with is something far more amazing than I was thinking at the Sun Tech Days. especially since, having seen google's solution, the number of issues that I was just plain not aware of are vast.

Let me mention however, that they have not solved the "deploy to thick client" - though in a sense their "hosted" mode is exactly that. I think because that need is in fact not required in any case. There are already API's available for building thick client gui's and besides, practically speaking thick and thin clients are so different that you would not be able to seemlessly deploy to whichever you choose.

Google's Web Toolkit - Summary of usage…

• They have built their own set of gui controls - the functionality of which can be realised in html. If you start using them, and you are familiar with html you will soon see this. They are "wrappers" onto the features of the html controls. They also have some of the familiar layout managers - DockLayout (BorderLayout), FlowLayout, TableLayout and others.
• They "translate" java code into javascript code. This, to be honest, is probably the biggest achievement of the google web toolkit. It is not therefore an AJAX toolkit as such. It is far more than an AJAX toolkit. This feature by itself is amazing. I have a sudoku puzzle solver that I built with a swing gui. I am very keen to see if it will translate into javascript so I can run it on the client (no AJAX). There are some limitations to what can be done, since java is not javascript. They also have a little bit more work to do on the parsing side - if you find that your code is not translating properly then you need to adjust the source code a little (it parses the java source code). The prospect of porting my sudoku solver to javascript by hand is not something I would dream of doing, this way I can see it in javascript, painlessly.
• Handle AJAX calls with standard RPC infrastructure but with additions to make it asynchronous. For someone who's done RPC in any context, a lot of the concepts involved will be familiar.
1. Build the remote interface, build the remote implementation of the interface
2. Build the Asynchronous remote interface - contains every method in the synchronous interface but with call back reference added to each call.
3. The process of calling is…
1. Instantiate the remote interface (on the client).
2. Specify the location of the "server" - in this case it is a servlet which you call.
3. Make the call - when making the call provide an implementation of the AsyncCallBack interface. AJAX familiar people will recognise this concept.

It didn't take me long to write a simple web application in google web toolkit which takes two numbers as input and multiplies them or adds them according to the button that is pushed. When I get a site I can place this kind of content on (zip files) I will put it there so that people can acquire it. For now, if you're interested, email me and I'll pass it on.

I'm using eclipse and created two run configurations for GWT compile and GWT run. When they mean compile however, what is interesting is that they're converting the java code into javascript code. Going from one language to another! Believe me, making sense of the compiled stuff is impossible - they've obfuscated it quite a lot and rightly so.

The payload can be fairly big - a fairly simple app I'm busy with comes to 82K. It might sound like a lot, but when you consider that there is absolutely no library code on the platform on which it is running it puts it into perspective. There is no big JVM required, the client only needs a browser.

All in all, it is an amazing tool. I'm not sure if it is ready to write business applications on - but I do think that day will come.

Google and AJAX - Wow!

A friend pointed out to me that google has recently released a toolkit for ajax, and how you can simply code in java and the toolkit will do the work of web enabling it. That looks absolutely amazing! I can't wait to try it out.

Thanks Trevor.

Build Ajax apps in the java language

Eclipse and Netbeans... which is it going to be?

Having attended the Sun tech days last week I was exposed for the first time to netbeans. Now it is my bad that I haven't investigated the merits of this very impressive IDE before, for from what I saw there, it is very impressive.

In fact, I would say that it is so good, that it is insane to give it away for free. Some of the industrial strength you-typically-only-get-them-if-you-pay-for-them features that it has are an awesome profiler as well as a collaboration suite that is just amazing. That suite along with some VOIP installation and you never have to get up and go to the other developers PC! In fact, you can probably do remote pair programming.

But what are the differences between Eclipse and Netbeans and why so much bad love between the two camps.

I think the initial bad love started when IBM decided to eschew swing and build their own gui API. Swing was slow and just not "nice". IBM's perspective was that having a GUI look and feel that resembled the OS's native gui API was preferable, and I can see there point of view. Swing, with all it's progress that has most definitely made, does not look as "nice" as the native gui API's (windows and GTK).

So I set about giving netbeans run with gusto. It wasn't long however, before my initial enthusiasm was repressed. Having been used to eclipse's rich set of refactoring and code productivity tools I frequently found myself frustrated that a samilar level of functionality is not available in nebeans. For instance, Netbeans does not have the following quick fixes: "create class" and "create interface".

Another one of Sun's gripes on Eclipse is that they use a non standard compiler. Sun wants them to use "javac" which they don't. I now understand why. The java builder (eclipse speak) is a much more powerful tool as it is far more "on the fly" than the java one. This is because it holds dependency graphs so that whenever a change is made all the files which depend on that change are also recompiled. In netbeans the appearance of an error is not immediate. The javac uses very basic "is the source file newer than the class file" to ascertain the need for a recompile.

I could continue... the debugger, is also not half as fully functional as the netbeans debugger.

In conclusion - I would agree that netbeans is a worthy competitor, the profiler, gui builder and collaborative tools are world class. However, developers spend far more time actually doing the work of editing and compiling, and this is where netbeans runs a distant second to eclipse.

Sun Tech Days...

I had the privilege, last week, of attending the Sun Tech Days. It was the first time tech days were held in South Africa, and it was worth the wait. It was two days jam packed with great ideas, great collaboration, lots of learning, lots of sharing, lots of excitement, lots of great food (The food was particularly good) and lots of free stuff (managed to score 2 t-shirts, a bouncy ball, a java mascot as well as a sun tog bag and id tag in addition to the netbeans book I won for answering a question!).

Over the next few days I shall be blogging on some of the details on the conference. For now I'll provide short synopsis.

The first day opened with a keynote from James Gosling. I must admit, it was great to see the so called "Father of Java" in the flesh! Nice to know these people are actually flesh and blood like you and me. His opening key note was not amazing but did provide a number of pointers as to Sun's thinking on java.

The day continued with tech sessions on various technologies and infrastructures, some of the key technologies touted at the convention were AJAX, BPEL (business process execution language), Netbeans - a world class IDE and EJB3.

Sun has a lot of experience running these days and I must admit, it showed. The days were well organised and ran smoothly, the speakers were interesting and for the most part excited about what they were talking about. There were exceptions to this, though these speakers were without exception, non sun people.

The sessions were generally, very tech oriented - one techie talking to another techie - (no marketing blurb) and though they were at times a little basic, necessarily so, they had enough content to keep the familiar parties, such as myself, happy. I'm sure if I was totally unfamiliar with the technology I would have found the basics to be very interesting.

Johannesburg is an amazing place - Sandton must have the largest concentration of head offices anywhere in the country.

All in all, the conference was a success. I'm very glad that I was able to go, thanks to my company for sponsoring the trip. Though the value they gained out of it was far more than the money they put in.