UltraLightClient reminded me of Droplets that were reviewed in the February issue. So I tried to figure out what the differences are. Here?s the result: 1) ULC integrates into J2EE servers while Droplets need their own application server, 2) ULC uses Swing on the client while Droplets uses AWT, 3) ULC?s server-side API is Swing-like while the Droplet widgets come with their own API, 4) the ULC client is pure Java while the Droplet client has some native code. 5) ULC uses J2EE communication infrastructure (HTTPS or RMI and IIOP) while Droplets use tunneling. Any other comments on this ?

Yes, the first three versions of ULC were done by Erich Gamma, André Weinand and their team at OTI (Object Technology International). It was an OTI/IBM internal product at that time. Canoo licensed it in 2000, productized it and took it forward, integrating it to J2EE etc.

This sounds like a product Erich Gamma and his friends have developed in the late nineties. Is there a connection ?

I agree with Ray.

ULC has API and programming model similar to Swing. The widget names and API names have been kept similar to Swing. So it is as if one is programming a fat client Swing GUI on the Server. In ULC, unlike in a Swing fat client, the client server distribution and communication is entirely handled by the framework.

As a programmer one doesn''t have to worry about
- sending/receiveing messages,
- distributing and synching object models,
- interfacing with middleware,
- optimising client server round trips,
- devising messy caching strategies
- dealing with multiple languages and technologies (JSP, Java Script,...)

and yet you get Rich Swing GUIs with an application independent thin client that deploys as an applet or through JNLP.

Moreover, seamless containment of ULC applications in the J2EE containers saves the pains of proprietary application servers and additional infrastructure.

There is an impliciation with the Canoo approach that was not readily apparent: this tool let''s one develop web applications in a manner much closer to regular Java/Swing style, with a regular compile/run/debug cycle.

In particular the contortions one needs to endure in a JSP/Java Script/HTML environment just go away.