Help coderanch get a
new server
by contributing to the fundraiser
  • 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Supporting API's in future releases

 
Ranch Hand
Posts: 99
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
I'm not dead! I feel happy! I'd like to go for a walk! I'll even read a tiny ad:
We need your help - Coderanch server fundraiser
https://coderanch.com/t/782867/Coderanch-server-fundraiser
reply
    Bookmark Topic Watch Topic
  • New Topic