NOTICE - removing all @deprecated code for GWT 2.0

[Fred Sauer]

To all GWT contributors-

As you may know, there many exciting things we're working on for GWT 2.0. With all the new features coming your way we thought GWT 2.0 would be a good opportunity to clean house and remove previously deprecated methods and classes. In many cases an equivalent replacement is suggested in the Javadoc and updating your projects should hopefully not be too onerous.

While different sections of the API have been deprecated in different releases we wanted to make things as straightforward as possible for the upcoming release. As such, our plan for GWT 2.0 is to remove everything that was marked as deprecated in previous releases. We did not introduce any new deprecations in GWT 1.7 so you can find the complete list of items we plan to remove in this GWT 1.6 document:

  http://google-web-toolkit.googlecode.com/svn/javadoc/1.6/deprecated-list.html

If you have any serious concerns about the above deprecation list, please reply back to indicate how you will be affected. In particular I'm interested in any use cases in the GWT 1.6/1.7 API which you feel would not be covered in GWT 2.0 once the @deprecated methods and classes have been removed.

Please note that Java compilers are required to warn you when your code uses @deprecated methods or classes. Although there are warning suppression mechanisms such as the @SuppressWarnings annotation and your IDE's or build environment's settings. So, in general, chances are you are probably not using any deprecated GWT APIs without knowing about it.

Thanks--

Fred Sauer

Developer Advocate

Google Inc.

1600 Amphitheatre Parkway

Mountain View, CA 94043
fre...@google.com

[Sam Gross]

Nice! I love house cleaning. :-)

Is there any plan for removing com.google.gwt.user.client.Element in
GWT 2.0 or some time in the future?

-Sam

[Isaac Truett]

Woo and, may I say, hoo, for removing deprecated code.

Will deprecated code in the Incubator be disappearing as well?
Obviously if that deprecated code depends on deprecated GWT code, it
will at least have to be updated.

On Fri, Jul 31, 2009 at 12:22 PM, Fred Sauer<fre...@google.com> wrote:

[tfreitas]

Yes, clean house :D

On Aug 1, 11:22 am, Fred Sauer <fre...@google.com> wrote:
> To all GWT contributors-
>
> As you may know, there many exciting

> things<http://code.google.com/webtoolkit/makinggwtbetter.html#roadmap>

> we're working on for GWT 2.0. With all the new features coming
> your way we thought GWT 2.0 would be a good opportunity to clean house
> and remove previously deprecated methods and classes. In
> many cases an equivalent replacement is suggested in the Javadoc and
> updating your projects should hopefully not be too onerous.
>
> While different sections of the API have been deprecated in different
> releases we wanted to make things as straightforward as possible for the
> upcoming release. As such, our plan for GWT 2.0 is to remove everything that
> was marked as deprecated in previous releases. We did not introduce any new
> deprecations in GWT 1.7 so you can find the complete list of items we plan
> to remove in this GWT 1.6 document:
>

> http://google-web-toolkit.googlecode.com/svn/javadoc/1.6/deprecated-l...

>
> If you have any serious concerns about the above deprecation list, please
> reply back to indicate how you will be affected. In particular I'm
> interested in any use cases in the GWT 1.6/1.7 API which you feel would not
> be covered in GWT 2.0 once the @deprecated methods and classes have been
> removed.
>
> Please note that Java compilers are required to warn

> you<http://java.sun.com/j2se/1.5.0/docs/guide/javadoc/deprecation/depreca...>

[Fred Sauer]

Isaac,

I would expect the maintainers of the various incubator 'ideas' to make an necessary updates. Similarly we expect the maintainers of other GWT related open source projects to make similar changes to their projects if they are in fact still using any deprecated APIs.

Good ideas that have worked out and have had long enough to 'incubate' should over time migrate to the main GWT project. Any final cleanup would be part of such a move.

HTH

Fred

[David]

Well,

I don't like it that API's are changed that quickly - well I don't
mind, it's my project manager that does not want us to spend time
redoing existing things.

But in our case most of the code is migrated to the new Event system,
it was a lot of work since we have many apps using GWT. We still have
a few custom components that were created with the old event
mechanism, but it will not be too much pain to finally move them over.

I guess we do not have much choice since we want to migrate ASAP since
we are constantly running against the limitations of the current RPC
system.

I prefer to code against a clean API so removing old stuff is good, as
long as you guys do not decide to use yet another event mechanism in a
few months - try to keep a stable API because constant rework of
existing software is not something managers like.

David

[Joel Webber]

Sorry about that, David. I can promise with reasonable impunity that we never, ever want to go through the process of changing the event system again (FWIW, I had the dubious pleasure of updating about a bazillion lines of Google teams' code to deal with this change at one point). We never would have done so in the first place if the first design hadn't had such obvious deficiencies.

[Joel Webber]

Sam,

I've been wanting to do this since we first introduced the dom package in 1.5. The plan is to remove all extant references to user.Element and friends, as well as the DOM.* static methods, at which point they can be deprecated. I'd like to do this as part of 2.0, so that we can go ahead and get them deprecated, but it remains to be seen if there's enough time in the schedule.

As soon as we do, though we should have a big party where we dance about upon the grave of the DOM class!

Cheers,

joel.

[David]

Joel,

I'll give your email to my project manager if you ever touch it again ;-)

David

[John Tamplin]

On Mon, Aug 3, 2009 at 8:30 AM, Joel Webber <j...@google.com> wrote:

I've been wanting to do this since we first introduced the dom package in 1.5. The plan is to remove all extant references to user.Element and friends, as well as the DOM.* static methods, at which point they can be deprecated. I'd like to do this as part of 2.0, so that we can go ahead and get them deprecated, but it remains to be seen if there's enough time in the schedule.

Do we have to remove internal references to it before marking it deprecated?  Obviously, those would have to be cleaned up before we actually remove it, but it doesn't seem necessary to require it earlier.

--
John A. Tamplin
Software Engineer (GWT), Google

[Joel Webber]

I'd be a lot more comfortable if our own code didn't have reams of deprecation warnings. The good news is that it's actually pretty easy to do -- it's damned near rote, though not quite enough to automate. I did it for a few large classes in 1.5 (though I didn't commit the changes), just to make sure I didn't miss anything too important.

[Fred Sauer]

I wonder how much work we could make Eclipse do for us. Under the 'Refactor' menu there are a few useful optional to record / playback refactorings:

Migrate JAR File	Migrates a JAR File on the build path of a project in your workspace to a newer version, possibly using refactoring information stored in the new JAR File to avoid breaking changes. Available: JAR Files on build path
Create Script	Creates a script of the refactorings that have been applied in the workspace. Refactoring scripts can either be saved to a file or copied to the clipboard. See Apply Script. Available: Always
Apply Script	Applies a refactoring script to projects in your workspace. Refactoring scripts can either be loaded from a file or from the clipboard. See Create Script. Available: Always
History	Browses the workspace refactoring history and offers the option to delete refactorings from the refactoring history. Available: Always
What if you recorded all the refactorings you wanted to make and then let developers simply replay them on their own projects? In fact, the Eclipse plugin could potentially prompt to auto upgrade projects to the new API. Fred

--

[Joel Webber]

I haven't actually tried any of this stuff. I'll definitely have a look when I hunker down to do this refactoring. Of course, if anyone wants to look into it before I get to it, that would be even cooler... :)

[Fred Sauer]

I've always been meaning to use it myself, so I just tried it and here's what appears to be the most useful thing you can do as an API or GWT developer:

1. Refactor your library using Eclipse

2. Review your history at any time with Refactor -> History

3. Package your refactorings

  - I did this via File -> Export -> Jar file (and then check the box 'Export refactorings for checked projects'), which produced a META-INF/REFACTORINGS.XML in the jar

  - I bet you could instead more simply use Refactor -> Create Script

4. Ship a jar with the new APIs and include the refactoring history in META-INF/REFACTORINGS.XML

Your users then simply:

1. Open their project while they still have your old jar in their classpath

2. They select Refactor -> Migrate JAR file

  - specify the location of the new jar file which contains the META-INF/REFACTORINGS.XML

  - specify the old jar already in their project classpath

  - Click, Next, then Next again

  - review the refactorings they want to apply

  - Click Finish

The rest is magic. Pretty cool. It wouldn't handle listener->handler migrations, but simple method name changes would be trivial. I tried it with an 'encapsulate field' refactoring. Works beautifully. You might even be able to trigger the user.Element -> dom.Element migration in user code.

Most excellent would be integration with the Eclipse Plugin whereby an update from GWT 1.7 -> 2.0 causes the Refactor->Migrate JAR file wizard to be invoked for you.

Fred

2009/8/3 Joel Webber <j...@google.com>