Eitan Suez's Blog

Where Swing should Venture

An increasing number of frameworks are appearing that I find particularly interesting. They're web AJAX frameworks where the details of the HTTP communication and of all the HTML and JavaScript on the front-end are hidden behind a Swing-like API.

Here are some of these new frameworks:

• NextApp's Echo2
• WingS
• Google's GWT

It's also worth mentioning that Canoo ULC also provides a Swing-like API, but they're trying to leap-frog AJAX altogether: they deploy Swing thin clients.

Even though this model is new and not yet "fully" proven, I find it very promising. Up until now, web developers have had to master multiple different technologies including Java, Servlets, JavaScript, HTML, HTTP, session management and cookies, and the idiosynchracies of various web browsers on a multitude of platforms.

These frameworks promise to collapse all of these layers down to one. That's tremendous.

So I was thinking, if what is essentially a Swing-like API can be used to build rich web applications, would it be possible to extend Swing in such a way that a deployment switch controls whether we produce a web application or a ... Swing application?

I suppose we could think of this in reverse: can an HTML look and feel be constructed for Swing?

The end result would be the same: we'd write a single application, using The Swing API (not a Swing-like API) and we'd be able to target the web without any extra effort.

So, my message in this blog is: I think Swing should venture in that direction.

Comments

• I'm wondering if the Swing release cycle could keep up with browser changes. Thats a big part of what these frameworks offer, abstracting away all the issues with display on browsers as you make the applications dynamic.

  BTW I read through the JMatter docs after John Reynold's blog about it. Very impressive framework. Too bad I work in the web!

  Posted by: ilazarte on June 30, 2006 at 05:32 AM

• it'd certainly be a project with a very large scope. it might have to be a separate project. but the idea of 'one api to rule them all' is appealing.

  thanks for the comment on jmatter.

  Posted by: eitan on June 30, 2006 at 05:50 AM

• have you see webcream?
  it does swing to web flying conversion
  http://www.creamtec.com/webcream/index.html
  

  Posted by: mceccarellitnx on June 30, 2006 at 05:58 AM

• I don't think that hacking Swing is technically feasible: Way too many AWT-dependencies, already messed-up class hierarchy, no databinding (ironically, we already have a Swing-like API with databding: JSF).

  I think the superior approach would be to define a new interface-based API which can be implemented using Swing, SWT, Java Gnome, JSF, Echo2, GWT or anything else as foundation.

  Posted by: scotty69 on June 30, 2006 at 06:21 AM

• Eitan,

  Cool idea, and I can very easily imagine something like Echo2 generating Swing... but from some reason I'm not confident that we'd be successful going the other way... Not sure why.
  
  I am very excited by the prospects of thin Swing clients, especially those constructed to still provide functionality when disconnected from the network (using something like Derby/HSQLDB)

  Browsers are really cool, but their very distinct programming model distracted us from the basics of client/server computing for the last 10 or so years. The end result was "Browser Classic", a Server-mostly form of computing.

  "Swing Classic" was pretty much a Client-mostly (often a Client-only) technology... If "New Swing" encourages designers to even out the balance between client and server, it could be very compelling indeed.

  -JohnR

  Posted by: johnreynolds on June 30, 2006 at 06:22 AM

• 
  Check out these frameworks

  [0] http://wicket.sourceforge.net/

  [1] http://swingweb.sourceforge.net/swingweb/

  [2] http://webonswing.sourceforge.net/

  Posted by: sullis on June 30, 2006 at 06:31 AM

• ...and one more for you to consider - in the XUI framework (http://xui.sf.net, http://www.xoetrope.com/xui) we have already started down a similar road for the forthcoming version 3.0. XUI can construct Swing and AWT pages from XML and in version 3.0 we are adding support for HTML (and SWT). The idea being 1) that we can consume HTML and render it as first class Swing components and 2) that we can attach/bind a Java application to an HTML UI as though the widgets were Swing components. Once that's done XUI provides data binding, caching and much of what you'd expect to see in a rich client.

  Some of the code has already been released and more will be added in the next few days. See the xui svn repository

  Using HTML in this way opens up many interesting possibilities but one of the difficulties is that HTML often includes lots of stuff that is unnecessary for a Swing application, for example nested tables for layout purposes. To counter this we hope to add a filter mechanism to filter out those parts that are not of interest - and indeed the filters could be interesting for many other purposes.

  Once complete these additions will allow you to switch between Swing and HTML renderings of the same application. However since there is so much more that can be done in Swing we envisaged that the 'lightweight' HTML UI might be used by casual users, with the Swing UI being used by frequent users or power users who would benefit more from the improved capability and peformance of a Swing UI.
  

  Posted by: luano on June 30, 2006 at 07:13 AM

• I don't like this logic too much. Building and html+javascript site without ever seeing the html and javascript ... sounds like something is wrong too me.
  What if you find a javascript error? If you never write JS you will not understand the error. And if you know what's wrong you can't fix it because you are not writting the code: the framework is. You depend 100% on the framework that writes the code.
  Plus framework limits you because it will not enable you to do everything that you could do in JS. And I don't mention the huge page size that you will end up with if you build complex ajax pages.

  In theory it is a good idea. In practice it will be a no no.
  

  Posted by: imjames on June 30, 2006 at 09:18 AM

• Good luck reimplementing Java2D in javascript.

  Posted by: amtiskaw on June 30, 2006 at 12:36 PM

• 
  Eitan, I attended the excellent presentation you gave at the June JavaMUG meeting in Dallas and I want to mention a few things on this subject.

  
  I think you're absolutely correct about the power of collapsing all the web development layers down into a single, unified development environment. I can personally attest to the benefits you gain from building an application on top of a web framework that operates in the manner you describe. In terms of speed of development and the richness of the UI, nothing can beat a web framework that leverages the full power of Ajax techniques to provide a highly interactive and rich UI, and does so with a pure server-side framework that allows you to develop exclusively in Java. Of course, you could say I'm somewhat biased since I helped build the open source ThinWire Ajax Framework ;-)

  
  Finally, and this is somewhat of a rant, so hopefully no one takes it personally. I honestly think Swing just needs to be sent off to retirement and removed from core Java. I can't remember the last time I spoke with a Swing developer who found Swing fun and easy to work with. The architecture tried to accomplish too much by trying to integrate an MVC approach directly into the GUI API. In my opinion the SWT / JFace approach is quite a bit more sensible. Add MVC if your application warrants the complexity, otherwise keep the API clean. Additionally, most people always want the native look and feel in there desktop apps and since SWT uses native widgets on all platforms, it looks perfect. With that said, you can probably guess that I don't think slapping an Ajax GUI onto Swing would be a good idea. Not because the concept isn't great, but beacuse Swing is too bloated at this point.

  Posted by: pra9ma on July 01, 2006 at 12:03 AM

• Doesn't Java Web Start already do all this?

  Posted by: pabas on July 02, 2006 at 05:26 AM

• thank you for your comments. it looks like i've got some work cut out for me. i'll try to spend a little time to research the various mentioned solutions (webcream, swingweb, xui, thinwire, etc..).
  

  Posted by: eitan on July 02, 2006 at 08:48 AM

• Think of it another way: in jMatter you start from the model and let that generate a GUI. Now here's a nifty little trick: imagine your model objects have an XML representation. You can then use a css stylesheet to display the data. (OK, for forms you need to do it a little differently, but that can be solved, read on). Now what about when you create the Swing gui? Well, with a FlyingSaucer panel you could either do the same in a Swing app, or, using FlyingSaucer's extensibility mechanisms you could let css handle layout and styling issues, but you could substitute each xml tag with a JComponent of your choice. Voilà! ( http://xhtmlrenderer.org )

  Posted by: tobega on July 02, 2006 at 12:03 PM

• DHTML+CSS+Flash+AJAX is much more powerfull than Swing. While there undoubtedly will be someone sooner or later that implements an AJAX Swing solution, it will never become a good way to do things.

  Given how ridicuouly slow the evolution of Swing/JAI/etc, I wouldn't bet 1 pence on it.

  Posted by: hvendelbo on July 02, 2006 at 04:37 PM

• I am thinking of starting a project to implement a JVM in Javascript for each popular browser. Anyone up for helping? I am thinking that the project will be called Multiplatform Abstract Deployment.

  Posted by: c_armstrong on July 03, 2006 at 03:35 AM

This work is licensed under a Creative Commons License.