- Full support for OS X development
Develop with GWT on OS X as easily as on Linux and Windows- Much faster hosted mode
Debug your GWT apps much more quickly. Hosted mode startup time has improved significantly -- and even better, refreshes are now lightning-fast -- even when your source code changes.- New HTTP request module
The HTTP functionality that you've been asking for (custom headers, status code, timeouts, and more), all wrapped up in an API that's easier to use than the JavaScript XMLHttpRequest object- Widgets in TreeItems
Tree items can now contain arbitrary widgets -- finally, it's easy to create trees with checkboxes :-)
InfoQ sat down with GWT tech lead Bruce Johnson to discuss the release. The interview started with Johnson discussing the issues found adding support for OS X and Safari:
There were a few surprises. It took quite a bit of exploration before we figured out how to best hook into WebKit. Although SWT already had some of the necessary Java bindings, we usually have to add more, including an extra layer of native code glue to make GWT's JavaScript Native Interface (JSNI) work. Once JSNI works, though, we're in great shape, because everything else is written in terms of JSNI. That makes for a very exciting porting experience because the moment JSNI works, everything works all at once: zero to sixty in only a few minutes.One unexpected challenge was a very hairy bug that affects SWT code running on OS X. It's actually too wacky to describe here, but the upshot is that you have to specify a magic VM argument -XstartOnFirstThread when running in hosted mode. It isn't a big deal in practice, because Eclipse on OS X always automatically adds it and we updated the applicationCreator to always add it. But it isn't ideal, and it'll be nice to get rid of that at some point.
There are still a few Safari-specific bugs we'd like to fix soon, but it will be much easier to fix them now that it's possible to do proper GWT development on OS X. Working with a real debugger sure is nice!
Next Johnson was asked about Google not using GWT for internal projects such as Google Docs and Spreadsheets:
Most of the Google products that are in the spotlight now were started before GWT was available, so naturally there are timing issues. However, based on the feedback we've been getting, some enterprises are increasingly showing confidence in GWT just based on their own positive experiences. Robert Hanson summed it up well on a recent podcast. To paraphrase him, "The first week you use GWT, you feel nervous because you're not sure if you can trust the whole 'compilation' thing. By the second week, you see that it really does work very well, so you stop worrying and start being really happy about it."
The conversation then shifted to the subject of 1.2 being the first GWT version termed a "Release Candidate" and the switch in the GWT development process:
It was essentially the release pattern we had been following anyway -- a big release followed by a refinement -- but we didn't do a good job of articulating how well-baked each release was. Anytime you make big changes and do fast releases, it's hard to be 100% sure you didn't break somebody out there in a subtle way. The "RC" designation is a simple way of saying, "We think this is ready for prime time, but please help us sanity check it first." If you're feeling particularly risk-averse, you can always skip the RC and wait for the final version.Finally Johnson, who recently presented at the Ajax Experience conference in Boston, was asked if he is seeing a difference in how JavaScript developers are reacting to GWT versus Java developers:
The typical reaction we see from Java developers is excitement and a sigh of relief. Often, they've done just enough JavaScript and DHTML to realize that the learning curve is huge, and they were not looking forward to trading their Java development tools and practices for the wild west of all-JavaScript development.JavaScript developers react differently. Some developers strongly prefer JavaScript as a language for its power and flexibility, viewing Java as too constraining. (Although what happens in practice, from what I've seen, is that JavaScript teams have to create rigid coding standards anyway to keep the code base sane.) Other JavaScript developers work in JavaScript because it's expedient and are not particularly religious one way or the other. They appreciate that GWT lets them use more powerful tools, facilitates reuse, and so on. And everybody seems to like the power and flexibility that JSNI provides. If you're a JavaScript guru, you can use JSNI to write JavaScript code and still easily share that code as a Java-callable library.