Wednesday, May 17th, 2006

Google Web Toolkit: Ajax Apps from Java

Category: Google, Java, JavaScript, Toolkit

<p>Google has released Google Web Toolkit (GWT), a code generation framework that lets you code Ajax apps in pure Java. It’s not unlike Echo2, the open-source framework from NextApp. A compiler performs the Java-to-Javascript translation.

  • Use your favorite Java IDE to write and debug an application in the Java language, using as many (or as few) GWT libraries as you find useful.
  • Use GWT’s Java-to-JavaScript compiler to distill your application into a set of JavaScript and HTML files that you can serve with any web server.
  • Confirm that your application works in each browser that you want to support, which usually takes no additional work.

GWT offers tools for remoting as well as a range of widgets: hierachical trees, tab bars, menu bars, and modal dialog boxes. There’s no mention of using these widgets standalone, but hopefully they can be used as pure Javascript widgets in much the same way as Scriptaculous can be used without Rails.

A widget like tree has methods to manipulate the structure (e.g. addItem()) and event handlers (e.g. addFocusListener). Here’s how a tree is created:

  1. public class TreeExample implements EntryPoint {
  2.  
  3.   public void onModuleLoad() {
  4.     // Create a tree with a few items in it.
  5.     TreeItem root = new TreeItem("root");
  6.     root.addItem("item0");
  7.     root.addItem("item1");
  8.     root.addItem("item2");
  9.  
  10.     Tree t = new Tree();
  11.     t.addItem(root);
  12.  
  13.     // Add it to the root panel.
  14.     RootPanel.get().add(t);
  15.   }
  16. }

Related Content:

  • Google updates Ajax tool
    Google Inc.'s release of the latest version of its Google Web Toolkit 1.4 for Ajax development is a "major upgrade to the company's open-source...
  • Inside the Google Web Toolkit
    Ed Tittel digs into the developer tools and Ajax functionality inside the Google...
  • Hot skills: Google Web Toolkit
    When Bruce Johnson , co-creator of the Google Web Toolkit,...
  • Ajax via Google Toolkit
    If you're looking to use the new Google Toolkit to build your next Web services application with Ajax, there's a tutorial article with code samples....
  • How Google does Ajax
    Using the Google Web Toolkit (GWT) compiler to generate DHTML from sources written in Java is explained in this Tech Brief from TheServerSide...

Posted by Michael Mahemoff at 3:39 am
24 Comments

+++--
3.5 rating from 109 votes

24 Comments »

Comments feed TrackBack URI

I was just having a glimpse over the docs… but i wonder if its possible to have moving panels like in google’s homepage or live.com?

Comment by Rui Nunes — May 17, 2006

It doesn’t have the smooth feel of Dojo, but it does seem to have good browser history integration. And you can debug right in eclipse… that’s nothing to brush off.

Comment by Matt Nuzum — May 17, 2006

I guess I am just impressed by what those guys are doing.
It might come from hell, but you gotta luv it

King is dead: long live Google

Comment by Quentin Dubois — May 17, 2006

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, http://code.google.com/webtoolkit/terms-1.0.20.html, 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 (*_*)

Comment by josson smith — May 17, 2006

Nice but fairly wacky. It conflates two separate ideas:

Browser-independent toolkit.
Java into JavaScript.

The second one no doubt appeals to many, although not to me since I am perfectly comfortable writing JavaScript. On the other hand, I’d love to see Google’s take on the all-too-common browser-independent toolkit in *JavaScript*, but apparently I’m not going to!

Comment by Jef Poskanzer — May 17, 2006

I think this is going to be a really interesting tool to work with.

Matt: Definitely feel you on the eclipse deal.

Comment by Brian — May 17, 2006

This isn’t at all like Echo2. Echo2 does most of it’s processing on the server and uses the browser only as a display. With the GWT, you can develop in a server mode to ease debugging, but you deploy a client-side script. You can make calls back to the server, but this framework at runtime looks more like Tibco GI or OpenLaszlo than Echo2 or ZK.

Comment by Dietrich Kappe — May 17, 2006

For give me for saying so, but I am surprised such a low quality tool kit from a great company like Google.

Their attempt to create a Java bridge helps neither Java developers nor JavaScript developers. Where does HTML fits and how does XMLHTTP works? It complicates already complex Ajax programming lot more.

I have been working on generative programming since 1999. Based on my experience, they would wish to focus on business logic and let web designers to deal with the JavaScript.

This led me to create a simple method for collaboration. The reusable GUI Classes must provide separation and let each individual work independently in a manner appropriate to their specific role and consistent with other roles, in a manner that reduces the interference between them. Please review a simple tutorial for code generators:
http://cbsdf.com/technologies/DHTML-Widgets/Widget-samples.htm

We know how this process works, GUI Class makers (e.g. Java/Swing or Borland/Delphi) build the widgets and application developers deal with business logic.

Where can I put business logic? It cannot to translated to JavaScript. Can it?

After looking at the code, they cannot solve many fundamental problems faced by other GUI Widgets.
http://cbsdf.com/technologies/DHTML-Widgets/TECH-Status.htm

Please ask yourself tough questions, how it is going to help Java developers? I simple cannot see, how it can help Ajax?

Please debate the benefits before you decide to flame me. I know a lot about this area and about needs of Java developers.

Best Regards,
Raju

Comment by Raju Chiluvuri — May 17, 2006

Actually, Raju, I think it vastly simplifies the lives of Java programmers and almost eliminates the need for JavaScript programmers — if you can make a pure GWT app. It makes writing a web app much the same as writing a Swing or AWT app. You don’t need to know HTML or XMLHTTP; they’ve abstracted those away, with HTML handled by the layout managers and XMLHTTP completely hidden inside the generated JavaScript code.

Where’s the business logic? It’s inside other classes, running on the server. AFAICT, when the translator sees a call outside of the packages it’s translating, it turns it into an RPC call back to your server.

Comment by Robert Crawford — May 17, 2006

Is it just me or is this reinventing the wheel? I think the code generation part of this is interesting. It seems a lot like DWR, except that it does a lot of stuff for you that DWR doesn’t. I think you have to actually write the javascript objects in DWR, here you don’t have to.

However, the whole layout aspect of this would make me want to tear my hair out. Didn’t they learn anything from Swing or AWT? Coding complex UI’s using East/West style layout is just plain frustrating.

If this were wrapped in JSF or there were some integration with some other existing java web framework (Struts? Tapestry? Webwork?) this would be interesting. But is anyone going to throw away their framework choices for this, when all of the major frameworks are also coming up with Ajax features? I think some of the ideas here will probably be adopted by other frameworks. The ability to debug javascript events in eclipse is pretty useful.

Comment by Tom Cunningham — May 17, 2006

It’s so cool that Google finally licensed Morfik’s JST.

Comment by Aardvark Face — May 17, 2006

Give GWT a chance and it will shine, as many other tools have. It does have the bells and whistles to handle both front & back ends. How well it will be accepted by the Java developers entangled in their frameworks of choice remains to be seen. But, let’s face it – it has been an evolutionary process and the great promise is still there.

Comment by Les Papier — May 17, 2006

This is quite intriguing.
Unlike Robert, my (early) understanding from reading the docs is that the business logic that you write in Java is actually compiled into business logic in Javascript.
There are a couple of things that it doesn’t understand though, like threads, longs and reflection.

More info at: http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.Fundamentals.JavaToJavaScriptCompiler.html

I’m assuming that you need your server-side logic (web services) separately from the UI.

Overall, it seems similar to haXe, but using Java as the development language rather than some new language. HaXe aims to compile to different platforms though, including DHTML/Javascript and Flash. Maybe GWT can be compiled to Flash too (like C#, see “Csswf” and other C# to SWF compilers).
http://haxe.org/intro

Comment by Julien Couvreur — May 17, 2006

[...] Google Web Toolkit: Ajax Apps from Java (Ajaxian) [...]

Pingback by GWT Site » Blog Archive » GWT announcements — May 18, 2006

I can see so many problems; I don’t even know where to begin

Do you want your business logic translated to JavaScript and exported to the Browser and executed in the browser?

It supports only parts java.lang and java.util, so you need to forget most of Java programming skills. No EJBs, no JDBC and forget about your CMS.

After all the sacrifices, do you really think, you can avoid JavaScript, think again. If you need to implement GUI Widget for a large custom DHTML component such as, Hierarchical menu of your own or Scroll for components (please see web page for an example), according to documentation on Google’s custom Widget implementation, you cannot avoid writing JavaScript code.
http://cbsdf.com/technologies/DHTML-Widgets/Widget-samples.htm

If you wish to implement a GUI Widget for a custom Ajax/DHTML component, you need intimate knowledge of the HTML elements, tags and even model. Therefore, you must have experience in both Java and JavaScript/DHTML programming.

Isn’t it the problem in the first place: to have clear separation between the Java developers (business logic) and JavaScript developers (presentation logic)?

To create an ideal solution, we need a model that let each work independently. The process must provide separation and let each individual work independently in a manner appropriate to their specific skills and consistent with their roles, in a manner that reduces the interference between them.

Web designers are great at creating great GUI components. We (java developers) must let them create great GUI Component with out any incumbarances, and once they have done that, we can create a GUI Class wrapper around it in an hour or two. This colabaration between Java and JavaScript developers must not be avoided, but can be made pleasunt by limiting to the functional requirements to just high level description of the couple of simple service the web component need to offer.

This problem is not going to go away, but will become even bigger as next generation web platforms such as SVG, XAML and MXML emerge. How do you create an Airplane to simulate near real-time air traffic in the skies?
http://cbsdf.com/technologies/GUI-Class3.htm (You need Adobe’s SVG Viewer)

These are just only few and many other obvious issues such as loosing the convince of JSP model etc.

Regards,
Raju

Comment by Raju Chiluvuri — May 18, 2006

There is good discussion on what it meant to Java developers at:
http://www.javalobby.org/java/forums/t72304.html

Comment by Denesh — May 19, 2006

[...] The Java Posse has been busy at JavaOne and recorded a couple of interviews on the high-profile Java+Ajax toolkits we’ve mentioned recently. Two Interviews about AJAX. The First is with Brett Taylor of Google about the just-announced red-pill project (also known as the Google Web Toolkit) and the second with Greg Murray of Sun … [...]

Pingback by Ajaxian » Java Posse Interviews: Google and Sun Toolkits — May 19, 2006

Google web toolkit (GWT) – A big move for Ajax

Google released GWT which automatically converts a Java based UI to Ajax last week. This obviates the need for the …

Trackback by Sast Wingees Speaketh — May 20, 2006

oh god again java programmer need to concentrate on user interface(UI)… it’s very bad idea .
reg ajax itz ok but , for developing javascript java programmer should not take risk.. it’s purely web designers job…
and moreover GWT hasn’t provided any IDE we need to use eclipse …
and moreover developing programs for GUI using awt and swings is really tedious ….. so it is similar technology which follows awt, and swings

Comment by saikrishna — June 2, 2006

Let me get this straight: Google have created a nice set of Widgets for Ajax/Javascript development and people are complaining? Whilst people may say there are already enough tools like this out there, I’ve gotta say phooey to you. The number of error prone bugy Javascript frameworks out there is high – but this looks solid, and it is still quite early in it’s development and seems to have a very active development cycle.

Raju said:
“No EJBs, no JDBC and forget about your CMS”

Umm, right. Only if you choose to use it that way. There are a number of blogs out there now which deal with issues of integrating this with existing frameworks – incorporating it inside a Struts page for example or in the larger context of a Spring application. Though it hasn’t been written to be integrated with these with good examples (and I think it’s crazy of them not to), where there is a will there is a way.

“It complicates already complex Ajax programming lot more.”

Again – qualify this statement? How does it complicate programming in Ajax? Does the idea of abstracting away from the various browser nuaces complicate things? Hell no. What about providing an intelligent way of sending objects to and from the server? I don’t know about you but I personally hate trying to make sense of XML responses myself in Javascript (kudos to DWC). Sure there are a few new ideas to learn, but once they have been learned, it helps ensure clean design – and thank god, means I don’t have to program in Javascript, though I can still debug it if necessary.

“Where can I put business logic? It cannot to translated to JavaScript. Can it?”

Business logic lives on the server – presentation logic lives on the client, though this framework would allow you to remove that restraint, good developers will be able to keep to that paradigm. Read through the docos a bit more, you’ll realise that not all classes get turned into javascript – check out:
http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.RemoteProcedureCalls.PlumbingDiagram.html

Comment by Dave — June 14, 2006

I am looking for Java Gui developer for one of my clients in Marlborough, MA. If anyone interested please get in touch with my toll free no. 800-435-3632 x607.

Anindita Ray

Comment by Anindita Ray — June 15, 2006

Hmmm…

Let me get this straight: Google have created a nice set of Widgets for Ajax/Javascript development and people are complaining? Whilst people may say there are already enough tools like this out there, I’ve gotta say phooey to you. The number of error prone bugy Javascript frameworks out there is high – but this looks solid, and it is still quite early in it’s development and seems to have a very active development cycle.

Raju said:
“No EJBs, no JDBC and forget about your CMS”

Umm, right. Only if you choose to use it that way. There are a number of blogs out there now which deal with issues of integrating this with existing frameworks – incorporating it inside a Struts page for example or in the larger context of a Spring application. Though it hasn’t been written to be integrated with these with good examples (and I think it’s crazy of them not to), where there is a will there is a way.

“It complicates already complex Ajax programming lot more.”

Again – qualify this statement? How does it complicate programming in Ajax? Does the idea of abstracting away from the various browser nuaces complicate things? Hell no. What about providing an intelligent way of sending objects to and from the server? I don’t know about you but I personally hate trying to make sense of XML responses myself in Javascript (kudos to DWC). Sure there are a few new ideas to learn, but once they have been learned, it helps ensure clean design – and thank god, means I don’t have to program in Javascript, though I can still debug it if necessary.

“Where can I put business logic? It cannot to translated to JavaScript. Can it?”

Business logic lives on the server – presentation logic lives on the client, though this framework would allow you to remove that restraint, good developers will be able to keep to that paradigm. Read through the docos a bit more, you’ll realise that not all classes get turned into javascript – check out:
http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.RemoteProcedureCalls.PlumbingDiagram.html

Comment by Dave — June 15, 2006

I reluctantly agree with the fact that seperating out Java and Javascript is sometimes important. (In cases where UI teams are extensively employed to setup the look and feel). However, I think this has been addressed fairly well by the GWT since look and feel is entirely in the CSS. This means that the UI “programmers” can work on only the CSS and HTML while even the presentation layer code can be taken by the Java techies.
Apprently Raju Chiluvuri has no clue as to what he is talking about. It does appear like a complaint made for the sake of complaining.

Comment by Neil — June 19, 2007

Although this blog is quite old, I just read through it and feel I need to back up Raju on his point that GWT does not provide separation between design and code.

If you’ve ever worked in a team with UI designers, they do a lot more than just format elements on a page (via CSS). A good UI designer will create interactions (like drag-and-drop), scrolling, handle pop-ups, create windows… they are supposed to have control over the entire UI, not just how it looks. That’s why they’re called User Interface Designers, not Make the Page Pretty Guys.

With GWT you can have a team that does stuff more toward the front-end of the app, and another team that does more of the back-end business logic/database stuff, but the line is blurred as Ruju points out.

Take a look at TIBCO GI to see what true separation of front-end from backend looks like. Someone please add this type of ability to GWT! It’s such a cool way to develop AJAX except for the page/module design part. How hard can that be to improve?

Comment by Mycole — April 2, 2008

Leave a comment

You must be logged in to post a comment.