Hello GWT community...
The release of GWT 1.5 was announced on a Wednesday at Google I/O,
and I attempted to pull it into our code that Friday/Saturday. It was
quite an adventure, and at this point I haven't fully resolved the
problems that have arisen. But I feel like I'm at a good point to
post my experience so far. Hopefully this information will assist
others that are taking on this task, and hopefully some of you experts
might have some feedback for me! :)
OS: Windows Vista
IDE: Eclipse
1) I started by simply swapping out the 1.4 API with the 1.5 API (all
relevant JARs, etc), and running our build script. The gwt-compile
portion failed, pointing at the use of a long in a JSNI method in the
Mapitz GWT wrapper for the Google Maps API
(googlemaps_gwt_2_2_1.jar). Using a long in a JSNI method is one of
the things that was discussed by the GWT team at Google I/O, and so
this seemed perfectly reasonable.
LESSON LEARNED: If you are using a 3rd party GWT library, the new
GWT 1.5 compiler might not like it, and you may have to wait for that
3rd party to release a 1.5-compatible version... or remove/replace the
library.
2) Unfortunately, the Mapitz library is no longer supported. This new
issue, along with several other issues with that library, led me to
push forward with bringing in the GALGWT library for the Maps API.
Getting started with that library had its own issues, which live in
the fuzzy boundaries of the scope of this posting, but you can get
that detail here...
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/b4676e34a4d48dce/df99d75b363ff7d2#df99d75b363ff7d2
Note in that posting that the latest build of the GALGWT for Maps
library, r290, is recommended. Also note that it is recommended only
if you are "not constrained to [GWT 1.4]", and so I found myself with
a 2-way dependency. In other words, I cannot upgrade to GWT 1.5
without upgrading the Mapitz library (see #1 above), and I cannot
upgrade to the latest build of the GALGWT library without GWT 1.5. So
I knew that both upgrades needed to be done together.
The conversion from the Mapitz library to the GALGWT library took a
few hours, but it wasn't as painful as you might think. Both
libraries are essentially wrapping the Javascript functions from the
Google Maps API, and so with both JavaDoc's handy, I was able to work
it all out.
LESSON LEARNED: Don't be afraid to switch from the unsupported
Mapitz library to the GALGWT library, which is a dependency for
upgrading to GWT 1.5. Just make sure you have anywhere from a few to
several hours to do it, depending on the number of places in your code
that use Mapitz classes.
3) Once I was pretty confident that I had completely converted to the
GALGWT library, I ran the GWT 1.5 compiler again, and I got an error
related to gwt-validator which I have reported here...
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/c1e1138942d23486/3a08ca17de50e18e#3a08ca17de50e18e
Note that this is another example of Lesson #1 above... we are
using a library that GWT 1.5 doesn't like. But this time it's not a
3rd-party library... it's a library that was made by Google!!
LESSON LEARNED: If you are using a GWT library created by Google,
themselves, the new GWT 1.5 compiler still might not like it.
4) Unfortunately, as you can see here...
http://code.google.com/p/gwt-validator/
...this library is no longer supported! So I was able to satisfy
the GWT 1.5 compiler by upgrading from the Mapitz library to the
GALGWT for Maps library, but for gwt-validator I have no such option.
So as a temporary hack, I grabbed the latest source for gwt-
validator, pulled it into our code base, and removed the JAR. This
allowed me to edit the gwt-validator source directly. If you look
closely at the error that I posted, you'll see that GWT 1.5 was not
able to create an IssueMessages instance via deferred binding. So I
changed the gwt-validator source to create an instance of
IssueMessages the normal way, and ran the 1.5 compiler. This time I
did not get any errors related to gwt-validator!
LESSON LEARNED: Don't use gwt-validator.
5) Although I had successfully removed the problem with gwt-validator,
this last run of the compiler was also unsuccessful. It turns out
that there were a few places in our RemoteServiceServlets where we had
neglected to use Generics, as if it were front-end GWT code, and the
compiler was complaining that this is not enough information to
properly handle the client-server communication (RPC).
LESSON LEARNED: The GWT 1.4 compiler does not throw errors when
your RemoteServiceServlets try to pass unparameterized objects
(Collections and Maps, mostly) to the front end, but the GWT 1.5
compiler does.
6) So I cleaned up the missing back-end parameterizations, and I
finally got a successful ant build!... er, well, it wasn't that
simple. It actually depends on how you define "successful"... The
GWT 1.5 compiler finished, but there were stack trace errors and
warnings flying through the console the whole time. Most of these
were due to misuses of "@gwt.typeArgs" that had been ignored by the
1.4 compiler.
LESSON LEARNED: The GWT 1.4 compiler does not throw errors when
your front end code uses "@gwt.typeArgs" on un-parameterizable
objects, but the GWT 1.5 compiler does.
7) So I published the output, and launched the site. The site is
certainly behaving strangely! At first I wanted to say that the GWT
1.5 compiler is too young to be considered reliable at this point, but
can I really blame the quirks on GWT 1.5? After all, as you've read
above, in the process I had to change my Google Maps API GWT-wrapper
library, change to running from the gwt-validator source, and then
blindly change an implementation detail in gwt-validator. Also, we
have over 3000 Java warnings in our code due to the 1.4 restrictions
on parameterization, which will be one heck of a Bugzilla issue to
clean-up from head to toe.
LESSON LEARNED: Don't just replace GWT 1.4 with GWT 1.5, and think
everything will be all hunky-dory. This is quite a task.
-Monkey Mike