Win a copy of Svelte and Sapper in Action this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
Bartenders:
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

Supporting API's in future releases

 
Ranch Hand
Posts: 99
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Does Google have any statements or guiding principals about the support of existing API's as new releases are rolled out? What has been the experience to this point?

Are there "best practices" a GWT developer can do to insulate the apps from API changes through releases? If so, are they covered in the book?

Why I ask this question: At our local Java user group meeting the other night, one of the programmers was complaining about a framework not supporting applications in future releases; how a certain framework rquired a re-write of the apps for the newest release of the framework. I think he was complaining about Tapestry, but I'm not sure.

Back support for older API's is always an issue with languages, operating systems, and frameworks.
 
author
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Charles McGuire:
Does Google have any statements or guiding principals about the support of existing API's as new releases are rolled out?



I don't recall seen anything written down directly as a statement, but everyone is very careful / aware of breaking API changes. A lot of discussion goes on on the contributor group (since GWT is now Open Source) http://groups.google.com/group/Google-Web-Toolkit-Contributors regarding changes and impacts.

Originally posted by Charles McGuire:
What has been the experience to this point?



Release 1.4 broke the approach to constructing a JSNI JavaSciptObject - however it was widely discussed and announced and a small change in limited amount of code.

There are some other examples here:
http://groups.google.com/group/Google-Web-Toolkit-Contributors/search?group=Google-Web-Toolkit-Contributors&q=breaking+api+change&qt_g=Search+this+group

Originally posted by Charles McGuire:
Are there "best practices" a GWT developer can do to insulate the apps from API changes through releases? If so, are they covered in the book?



Stay away from, or at least be highly aware of experimental aspects is really the best advice.

GWT contributors also make the best attempts to protect you too - most of GWT is stable but in the latest release there are a couple of widgets where the internals are not completely sorted out. Methods affected in this case they have been marked final to prevent eager people subclassing minimising the chance of being caught out if changes occur in future release.

There is also the potential for a tool being developed to highlight such issues (see Bruce Johnson's post above the post in this link http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/215a21405162fdd2/e337ebef1684fd36?lnk=gst&q=breaking+api+change&rnum=8#e337ebef1684fd36)

//Adam
    Bookmark Topic Watch Topic
  • New Topic