GWT: Gotcha's

Question

My team is embarking on its very first GWT project. We are fairly strong with Swing applications, with almost all of our work involving significant Swing GUIs.

However, this is our very first foray away from the Desktop and to the Web, and the project requires us to use GWT. The project itself is pretty straight forward, the only unknown to us being replacing the Swing UI with the GWT UI.

What pitfalls should we watch out for?

Answer 1

Not using GIN and Guice. Dependency injection is very, very useful. GIN (Guice for GWT) isn't documented very well but is worth the time investment spent getting it to work.

Answer 2

Different browsers have quite different performance characteristics, so you'll have to test against different browsers even though GWT generates Javascript workarounds for browser differences.

Creating DOM elements can be very slow in some browsers. If you have large-ish tables (dozens of rows) that change frequently, the browser can become unresponsive if you just delete all the rows and recreate them. We had to write a diffing algorithm to efficiently update tables when new contents were fetched from the server.

Answer 3

I can think of a few:

• Everything is asynchronous. Well, anything service-oriented at any rate. While Swing sometimes acts like this via SwingWorkers and the like, Swing is fundamentally synchronous via the EDT (event dispatching thread). It can take a bit of getting used to;
• You're in for a world of hurt known as CSS and cross-browser compatibility. While GWT does mask many of the differences between browsers, it certainly doesn't mask them all and you can spend hours looking for the source of a line of pixels in GWT just as you can in a normal Web Site;
• There are far fewer resources for Swing than GWT;
• You can only use certain classes on the client-side. The one that used to always cause me issues was BigDecimal;
• Your choices of widgets is far more limited. Whatever you do avoid ExtGWT like the plague. Daryls is like the Jeffrey Dahmer of Generics;
• Make sure you use GWT 1.6;
• The compile-time on GWT is just horrific;
• If you're just making client changes (ie you're not changing any service interfaces), you don't need to rebuild to see those changes. Just refresh in the hosted browser;
• For changes to serverside code that doesn't change the interfaces, make sure you have an Ant or Maven task to rebuild and redeploy your classes without doing a GWT rebuild;
• You can point the hosted browser at something other than the hosted server and debug using it; and
• Make sure your machine has lots of RAM. My IDE on some apps would get out of memory errors if less than about a gig of RAM was allocated to it and these weren't huge apps. I would really recommend 2gigs system RAM absolute minimum, preferably 3 or more.

Answer 4

I ran into an issue where trying to populate tables through nested collection didn't work, presumably because the compiler didn't understand it (issue @ GWT list). Note that this was about a year ago, so it may no longer be the case.

Second issue (again, a year ago, so may no longer be the case) was that compiling on a 64-bit box with a 64-bit JVM wasn't supported, so I ended up needing a separate 32 bit jvm and wrapping an ant task that specifically referenced that for the GWT compile setup.

Answer 5

To expand on what Cletus said about "certain classes", you do not have a full JRE on the GWT client-side. (Remember, GWT Java client code is translated to JavaScript.) This means that third party Java APIs will often not work client-side. They need to be ported for GWT. So much for write once, run everywhere. See here for more information about this limitation.

Answer 6

Most of these are still 100% relevant to what you want to do:

http://stackoverflow.com/questions/99866/biggest-gwt-pitfalls/99977

To specifically address the Swing -> GWT Transition there's one simple rule:

• GWT is not Swing, and to build a good app you always have to know at some level what kind of HTML the widgets you are creating will produced, and every now and again you will have to get down and dirty and modify some of the behaviour or even code some custom parts in javascript or HTML.

Answer 7

One major gotcha to keep in mind is testing. Testing a swing app with junit is mostly straight-forward, but in order to get that level of coverage on a gwt app you'll need to widen your arsenal.

1. Straight junit - This is suitable for model classes/utility that don't reference any of the gwt runtime. Just write and run your tests as normal junit, just make sure gwt doesn't try to compile your test code into your module. You can't always factor your classes to get this kind of coverage, but when you can its great and fast.
2. GWTTestCase / junit - This is a special TestCase subclass (junit3-style) that will bootstrap some gwt runtime for the test run. In my experience, it too difficult to get good coverage and is too slow to be useful. Read this for more on the subject.
3. Selenium - This will get you coverage in-browser (and is personally my favorite approach). If you use java selenium-rc and combine it with jetty to serve up your app-under-test, you can even mock out rpc calls to fully test your ui. You also have the ability to run your tests in all the major browsers.

Answer 8

Even with 4 gigs of RAM you can have issues compiling your app (on GWT 1.6 and prior). I'm not able to compile our (rather large) app at work using Maven/whatever. Hosted mode works ok, but no setting (upping vm memory constraints to 2 gigs etc..) seems to resolve this.