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...
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...
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.
...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.
our experience: 1) the GWTWidgets library is not compatible with GWT 1.5. We made minor modifications. 2) i18n - we had to change all the single apos ' to two apos '' in the messages_xx.properties files 3) the warning message for typeargs can be suppressed by adding "-loglevel ERROR" to the gwt compile step 4) update the gwt-servlet.jar file to match the GWT version on the client
-------------------------------------------------- From: "MonkeyMike" <mikebin...@gmail.com> Sent: Tuesday, June 03, 2008 12:53 PM To: "Google Web Toolkit" <Google-Web-Toolkit@googlegroups.com> Cc: <m...@nileproject.com> Subject: Lessons Learned during upgrade to GWT 1.5
> 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...
> 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...
> 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.
> ...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.
I basically turned on the java 1.5 warnings in eclipse (normal things eclipse whines about in java 1.5) and started chasing little yellow exclamation points. Once I'd eradicated them all from my project (mostly whining about generics), and removed the @gwt.typeArgs pseudo- annotations, I compiled and deployed the result ...
everything appears to work as expected ...
I've begun removing some third party libs (mostly mine) and replacing them with built in functionality from GWT 1.5.
> 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...
> 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...
> 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.
> ...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.
On Jun 3, 9:53 pm, MonkeyMike <mikebin...@gmail.com> wrote:
> 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...
> 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.
gwt-validator is not a Google project at all AFAICT, so actually it
falls under your first lesson learned, as with Mapitz.
> On Jun 3, 9:53 pm, MonkeyMike <mikebin...@gmail.com> wrote:
> > 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...
> > 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.
> gwt-validator is not a Google project at all AFAICT, so actually it
> falls under your first lesson learned, as with Mapitz.
