Canoo has released a new plug-in for Eclipse 3.0 that simplifies Rich Internet Application (RIA) development with the UltraLightClient (ULC) Java library. The new plug-in provides a tight ULC integration into the Eclipse IDE, enabling developers to deliver pure Java-based RIAs.

Building Rich Internet Applications in Java

UltraLightClient (http://www.canoo.com/ulc/) is a library to build Rich Internet Applications (RIA) in Java. Offering a server-side programming and execution model, it is the ideal complement for the Eclipse Rich Client Platform (RCP). With this standard Java library, developers will be very effective in providing rich, responsive graphical user interfaces (GUIs) for enterprise web applications within J2EE and J2SE infrastructures. UltraLightClient builds on available developer know-how by following the Swing API, yet shields the developer from the complexities of client/server code distribution by taking care of the code split and by optimizing communication. Application releases are deployed on the server only. The user interface is handled by an application-independent Java presentation engine distributed as an applet to a browser, to Eclipse RCP, or via Java Web Start.

UltraLightClient is available for purchase at http://www.canoo.com/ulc. A developer license costs US$ 1495 and includes free runtime distribution on any number of servers. A free evaluation license may be obtained for 30 days.

The new Eclipse Plug-in

Dedicated wizards guide Java developers through the steps required to create a new project, automatically linking all necessary UltraLightClient libraries and defining a clean structure. The plug-in generates a sample ULC application that can be used as a template to understand the use of a launcher and the structure of a main class in ULC. Updating an existing ULC project to a new ULC version is carried out automatically. The plug-in streamlines the export procedure to deploy a productive application as an applet or using Java Web Start.

The plug-in source code and documentation is available for download at the UltraLightClient Community website
(http://ulc-community.canoo.com/).

Source:
http://www-dev.canoo.com/news/ulcintegrationplugin.html

Yet another framework. This clearly demonstrates that:

• Everybody wants thin applications;
• Everybody wants thin applications to behave like GUIs.

My point is - you want thin apps, use nice-looking, simple interaction UIs (Struts, Spring, etc.); if you want feature-rich UIs use Swing. Please, concentrate on how you can improve the existing ones, do not invent another wheel.

Yet another framework. This clearly demonstrates that:

• Everybody wants thin applications;
• Everybody wants thin applications to behave like GUIs.

My point is - you want thin apps, use nice-looking, simple interaction UIs (Struts, Spring, etc.); if you want feature-rich UIs use Swing. Please, concentrate on how you can improve the existing ones, do not invent another wheel.

And that's exactly what the ULC library does: it uses Swing. I therefore rightly conclude that you favor this library?

try http://www.thinlet.com (LGPL)

try http://www.thinlet.com (LGPL)

Thinlet is nice but too limited IMO.
http://swixml.org/ + Hessian protocol and started with Java Web Start is capable of delivering Zero Administration Clients with UI of any complexity.

Thinlet is nice but too limited IMO.http://swixml.org/ + Hessian protocol and started with Java Web Start is capable of delivering Zero Administration Clients with UI of any complexity.

Konstantin, I agree with you that from a purely technical standpoint this is a killer combination of technologies - especially when used with Spring and Hibernate.

But do you find that customers are willing to install Java Web Start? I would love to think the answer is yes, but I'm not sure it's something you could count on, and so would end up re-doing the client software using a different technology for some customers :(

What have been your experiences with regard to this?

Mike.

Thinlet is nice but too limited IMO.http://swixml.org/ + Hessian protocol and started with Java Web Start is capable of delivering Zero Administration Clients with UI of any complexity.

Konstantin, I agree with you that from a purely technical standpoint this is a killer combination of technologies - especially when used with Spring and Hibernate.But do you find that customers are willing to install Java Web Start? I would love to think the answer is yes, but I'm not sure it's something you could count on, and so would end up re-doing the client software using a different technology for some customers :(What have been your experiences with regard to this?Mike.

Yes, I was able to convince customers to install JWS and they were exited being able to edit organization hierarchy Tree with drag-n-drop.
- That was a category of customers that frequently use an application and JWS Tree editor was created as complementary to the main HTML application frontend.
-Yes. I admit that we cannot count on JWS available on client. But in the same time I do not understand why. I guess it is because JRE is harder to install than Flash plugin.
But it does not have to be. Why JRE seed cannot be small and able to load pieces of itself lazily on demand?


IMO problems should be addressed in the right place. In the case of rich UI it is the availability of JRE-JWS on client. Fixing this one problem will enormously simplify job for many developers (and free Macromedia from recreating JRE under Flash brand).

Another missed pieces in the puzzle:
1. True JWS support for applets (http://kgionline.com/annoying/java/annoying_java.jsp#jws_and_applet).
2. Availability of trusted repository from where JWS will download libraries only once (and appropriate changes for codebase spec) – that will enormously DECREASE applets size, because their codebase will include only custom code.

Konstantin,
I'm currently coding a small feasibility test of the combination Thinlet + XmlRpc. I opted for this combination because it only requires a jre 1.1 on the client (=applet). Can you explain why SwiXml + Hessian in your opinion is better suited?

Regards
Koen

Konstantin,I'm currently coding a small feasibility test of the combination Thinlet + XmlRpc. I opted for this combination because it only requires a jre 1.1 on the client (=applet). Can you explain why SwiXml + Hessian in your opinion is better suited? Regards Koen

I was initially very exited about Thinlet, tried it and then realized that there is too much needs to be implemented to be usable for 'advanced' UI.
For example it does not support cell editor in table or list.

SwixML is actually optional, as long as UI definition is kept separate. I have found Java UI definition to be more convenient to deal with, you know all that coloring, code complete, syntax check etc.

IMHO this doesn't hold a candle to Flex/Flash based RIAs. The demo's are ok but really impressive. In addition to the JVM startup, it also takes quite a while for a first download.

Marc

IMHO this doesn't hold a candle to Flex/Flash based RIAs. The demo's are ok but really impressive. In addition to the JVM startup, it also takes quite a while for a first download.Marc

Swing come with skinnability and http://javootoo.l2fprod.com/ has references to various LnF. ULC samples will look much more impressive if started with Liquid or Napkin LnF...
IMO: Properly skinned Swing is way better than Flash (Flex or Laszlo)

The bonus of UltraLightClient's approach vis a vis other solutions is its pure architecture that leverages Java standards:

- it's just a rigorous implementation of the HOPP pattern for Swing resulting in 50'000 pure Java LOC, and not a big framework

- your programming model is standard Swing (component-based, event-driven, MVC), and not a mixture of proprietary stuff (JavaScript, some XML langugage...)

- native Swing is used on the client

- communication over standard J2EE channels come for free (HTTP(S), RMI/IIOP(S), etc.)

- your apps will run in any J2EE container or stand-alone

- there's no proprietary server: session handling, clustering etc. are delegated to the J2EE container

I think that Java Applets look dated since the release of JavaServer Faces.

There is a requirement for Swing based applications but I see this in the segment of desktop oriented applications, not the web.

Building on Swing to compete with JavaServer Pages and JavaServer Faces simply means fighting the wrong battle.

Use Swing for what it is good for: Desktop oriented applications that have their business logic on the client or the server, but that have their application logic on the desktop. I don't see how Canoo could deliver off-line (local) support as needed by many business applications.

I respect that Canoo came up with ULC to a time when JavaServer Faces wasn't on the radar and JSP was in its release 1.0. The world didn't stop spinning and the cards are shuffled today.

Frank

The point about UltraLightClient is not that its presentation engine may be executed as an applet (it may be deployed with JWS, too). The point is that you have a client/server application with a rich UI that does the client/server code split for free, runs on any (existing) J2EE web platform, and is not limited to HTML like JSP and JSF. You may, of course, also mix&match it with JSP & JSF, i.e. provide a rich UI channel for an HTML-based app. (by sharing the servlet context, for instance). For the offline scenario, ULC provides a client/server simulator that allows you to run both client and server in one VM. Applied cleverly, this allows you to write apps that are both stand-alone and scalable multi-user server apps at the same time (with a single code base). ULC has evolved a lot since its early versions...

I think that Java Applets look dated since the release of JavaServer Faces. There is a requirement for Swing based applications but I see this in the segment of desktop oriented applications, not the web. Building on Swing to compete with JavaServer Pages and JavaServer Faces simply means fighting the wrong battle.

JSF is a duck tape solution.

I think that Java Applets look dated since the release of JavaServer Faces.

In my opinion there is no killer java UI-technology to build web applications. It all depends on the audience you're targeting (one-time users >< occasional users >< regular users, internet users >< intranet users) I can imagine that one-time users will be perfectly happy with a completely server controlled application build with JSF-tehnology. But I'm certain that daily intranet-users will find the application primitive and demand a better user experience. In these circumstances an applet based UI can be a better option.
No doubt, JSF is state of the art. But using the Html Renderkit and hence building your UI with Html-forms is definitively more dated then building the UI of your application with applets. Yes I know the JSF-standard does not impose you a particular rendering technology. But the only option you have currently is sadly enough the Html renderkit.

Regards,
Koen

Nice, but too expensive, since there are good and free alternatives.

www.openlaszlo.com
www.xulplanet.com

Nice, but too expensive, since there are good and free alternatives.www.openlaszlo.comwww.xulplanet.com

Is 'ha_ha' == 'Gerald Bauer'? :)

ULC has arguably the best price compared with other commercial RIA solutions. A ULC developer license costs 1495 $, runtime distribution is free.

See the ULC price list at:
http://www.canoo.com/ulc/products/index.html

Most other commercial solutions come with expensive runtime server licenses.

In a commercial project, ULC cost is negligible. What counts is how much the technology saves in terms of development time and runtime cost, which depends on quality and functionality.

We don't think any of the free or OSS alternatives is a match to ULC in this respect.

regards,
sandra


P.S. I entered the wrong URL in my posting above. The correct URL is:
http://www.canoo.com/news/ulcintegrationplugin.html

See also Marc Domenig's article discussing evaluation criteria:

http://www.javalobby.org/articles/ajax-ria-overview/

The article discusses some of the decisions you have to make when choosing a RIA framework.