AjaxSwing can be thought of as a runtime Java to HTML converter that creates HTML and JavaScript at runtime, unlike GWT that creates it at compile time. AjaxSwing is unique in that it requires no modifications to existing Swing windows and business logic, and does not require programmers to learn any APIs outside of core Java and Swing.
Companies that has invested years of development time and hundreds of thousands of IT budgets into building Swing user interface have a tough decision to make. They can continue to develop using Swing and deploy using WebStart, which requires client-side maintenance and is not a true thin client.
What's new in 2.3
* Server-side push that allows pushing the updates to the browser without user interaction
* Server-side rendering and emulation optimizations that improve performance by up to 50%
* Client-side JavaScript optimizations that improve performance by up to 50%
* Visual improvemens throughout the product
* Safari brower support on all platforms including iPhone
* Google Chrome brower support
* Various bug fixes that provide better matching of Swing functionality
http://www.creamtec.com/products/ajaxswing/

I think that's comparing Apples to Oranges. DWR "is a RPC library which makes it easy to call Java functions from JavaScript and to call JavaScript functions from Java (a.k.a Reverse Ajax)." It is a nice framework for applications that have Java back-end and JavaScript front end.
AjaxSwing is a framework for deploying pure Java applications with Swing UI as HTML/JavaScript. It is very useful for migrating existing Swing applications into thin browser-based model (http://www.creamtec.com/products/ajaxswing/solutions/swing_to_GWT_and_AJAX.html)
The main differences are:
- DWR is simply an RPC mechanism for mixed applications where client is hand-coded JavaScript and server is Java. AjaxSwing is a complete solution for pure Java applications, both on the client and the server
- DWR doesn't have UI components/widgets, while AjaxSwing supports all standard Swing components
- AjaxSwing allows running applications in dual mode - as a Java Swing application via WebStart or installed locally, or as a AJAX application remotely via browser
Being able to use Swing API has obvious advantages for migration and learning for Java developers who already know Swing.
Having said that, I'm not an expert in DWR so please feel free to correct me.

No, because just like GWT the JavaScript/AJAX is the deployment artifact, only used by the browser. Unless you want to customize or enhance the functionality (like create your own AJAX components) you don't need to learn it. You just use Swing components and APIs and AjaxSwing converts it to JavaScript when the application runs.
http://www.creamtec.com/products/ajaxswing/solutions/convert_swing_to_ajax.html
Take a look at standard Java's SwingSet example running on creamtec.com or with the downloaded product. You can view the source for each tab and you won't see any JavaScript or HTML there. Nothing but pure Java:-)

If if generates JavaScript and Ajax code, wouldn't developers have to be familiar with that code?

How familiar are you with the JavaByte code?
However I share your worry - behavior of browsers is far from being as consistent as behavior of JVMs and therefore those 'deployment time artifacts' cannot be yet treated as bytecode we unlikely need to look at.
I would say that if your project and UI usage is OK with the jungle of JScript the GWT produce, you may better off writing UI in Flex. Pleasant platform to develop on and much less layers on indirection plus true bytecode for Flash VM. And FVM behavior is more consistent and predictable than behavior of browsers.

Personally I prefer GWT and AjaxSwing over Flash. You write your entire application in Java, unlike Flash where your UI is ActionScript which is pretty much JavaScript.
Unless you need something very graphical (like Yahoo Interactive stock chart) I see no reason in using Flash. Modern AJAX apps are just as cool and powerful as Flash. Why limit yourself to a plugin when you deploy directly to the browser?
Case in point is iPhone. It runs AJAX apps right out of the box, but it still has no support for Flash UI and no way of telling when and how complete it would be.

.. You write your entire application in Java, unlike Flash where your UI is ActionScript which is pretty much JavaScript...

Not really, if you use Flex. Then UI is defined in markup, and logic is defined in the ActionScript. And AS has very nice features like bindable variables which significantly simplify implementation.
Flex has bad reputation because of Flash abuse for ads, but Flex is add-on that boosts development productivity even in cases when pretty UI is not required, however it allows prettifying UI to any degree desirable.
As for iPhone support for Flash - there are non technical reasons for lack of Flash support. And if you want app for iPhone it is better to use its SDK, because that Ajax application has little chance to work even on decent BlackBerry.

No, these days most of mobile browsers support Ajax, including new BlackBerrys Storm and Bold.
I invite you to see this list.
Returning to AjaxSwing, I must recognize is impressive, porting Swing to web is a really hard task.

Unlike GWT that creates it at compile time AjaxSwing and Echo2 do not let you control over html elements as well as DOM event model. The css support is also limited in AjaxSwing and Echo2.
When you build something that should look and feel similar in all browsers GWT is best solution so far.
If want to convert your swing application to web application echo2 or ajaxSwing should be your choice.
Regards

Unlike GWT that creates it at compile time AjaxSwing and Echo2 do not let you control over html elements as well as DOM event model. The css support is also limited in AjaxSwing and Echo2.

I agree that GWT has advantages over AjaxSwing but I wouldn't say CSS is one of them. When you program with GWT you'll end up using controls, which is the same thing that you'd use in AjaxSwing. AjaxSwing is fully CSS driven and within the limits of the controls is just as stylable as GWT.

When you build something that should look and feel similar in all browsers GWT is best solution so far.

If want to convert your swing application to web application echo2 or ajaxSwing should be your choice.

Regards

Again, I don't think cross-browser look and feel is an issue, because AjaxSwing apps would look the same in all browsers.
I think the main advantages of GWT over AjaxSwing is that you can program client logic in the browser. So simple validations and event responses can be done very quickly without going to the server. On the other hand, GWT limits what you can do on the client (e.g. you can't really use Spring, you have issues with using Hibernate etc) so it's a tradeoff.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.