GWT Generator's TypeOracle has the privilege of understanding the entire world, and knowing about all classes that exist - this is an aspect of what makes GWT so expensive to run, since it have already collected all of that.

In contrast, the processor environment tells you only what classes are currently being compiled so you can handle them - at least in theory, if someone doesn't edit a class that is important to your codegen tools, you will not be told about it (since nothing happened). For something like UiBinder, Constants, ClientBundle, Places, SafeHtmlTemplates this makes good sense. For other tools where you need to understand the whole world, we need to learn to think in APT a little better. Specifics for that depend on your exact use case.

...But if all the code you ever will need from getTypes() is in one project and _every_ build is a clean build, and you don't mind your processor being required to run on everything (like Generators did) which may slow things down, you can request "*" as the annotations you want to handle, and then "roundEnv.getRootElements()" will give you all types. Again though, this makes a few important assumptions about how your project works - either IntelliJ or Eclipse will try to rebuild your project without doing a full clean build.

One power that APT has that generators do _not_  is the ability to run multiple times on the same type, and run until everything settles out completely.

EDIT: I'm working up a list of many calls that are made on the gwt JType hierarchy that don't apparently exist in APT, and will publish it once I have confirmed the correctness of a few more of them. For now, you might consider looking at the existing GWT generators and their corresponding ported APT versions.

@Helmut it is a pain to be sure. Here is what I can tell you, and what we have been saying since GWT 2.7:
If you are using JsInterop and otherwise gwt-legal java, your code will work in 2.x and 3.x. We also know that J2CL will compile individual Java files to JS, and that the (already open sourced) Closure compiler will perform the optimizations, as it does for so many other prominent JS-based applications.

GWT 2 continues to advance (see my talk for more on this...) - GWT 2.8 added java8 support, 2.8.2 will be out soon providing the ability to run on JDK9, and GWT 2 development is not stopping just because GWT 3 will exist someday. There is at least one fork out there which even has had Java9 language support. If you are watching the commits to GWT 2, they are ongoing from both inside Google and outside. I'll speak more about all of this at the conference.

Angular is a bit of a different story - by my reckoning, Angular 1 wasn't worth using for any data dense application, and I'm led to understand (though haven't yet tried) that Angular 2/4 still has similar issues. If we released "easy-to-use" but hard to deploy and _support_ software as angular, I would agree we would need extremely detailed advice on how things will look, and what you will need to write. But GWT is stable and mature, and moving to GWT 3 will _not_ require you to change languages, or entirely rewrite your application as you shift - you can do it before (and if my suspicions about how J2CL+Closure works are correct, we may even be able to continue some aspects of migration afterward).

If you are following the guidelines about how to write code for "GWT 3", then your code is already compatible with GWT 3. If you are writing an application that will be _finished_ before GWT 3 even launches, then you can maintain GWT 2 compatibility, as it continues to be improved. If you just stub in GWT 2-only features like GWT's existing generators, then take part in discussions here (and the mailing lists, gitter, etc) to see how those can be migrated to GWT3-compatible tools, like APT.
 

Well, we don't really talk code in _those_ meetings - there are no github projects or links passed around (except to "hmm, we better ship an update soon because of that bug report"), nor youtube videos, and rarely any real "presentations" (though they do happen).

The current plan and expectation is that GWT 2.x will not remove GWT.create(), nor even legacy Dev Mode - for teams still using these things, the maintenance is low and the benefit is high.

With that said, neither are getting updates to bring them into the future - no jsinterop for legacy dev mode, and no java 8 (or soon, java 9) language features for generators.

If you're using Angular, are you even using JS? I thought I had understood you'd be learning another transpiled language - TypeScript - and while that adds some less-weak typing, I'm not sure it gets near the assurances of Java.

Thanks for the feedback - we have some limitations here in what we can talk about in general, please forgive how the process has to work.

The plan for GWT3 is ongoing, and we already know what the language will look like - Java, with JsInterop to talk to non-Java code. The build system and the ecosystem makes for a more complex topic, though until the tools are ready to be used there isn't much to say. The ecosystem on the other hand - that is a topic that can be started already, and need not wait on anything more from the steering committee or GWT contributors - JsInterop is here and stable, Elemental2 is approaching stable, and we're already seeing new tools and ideas pop up like elemento, and research across the community into APT.

Frank, I personally think you are right about widgets, even if they aren't com.google.gwt.user.client.ui.Widget - why even use Java if we don't have rich, well thought out abstractions that we can code against. Many of us are experimenting with work to port existing GWT staples into a future without jsni and JSOs - nearly all of them look reasonable and some might even not require any substantive changes at all in downstream projects.

Here is the one argument against com.google.gwt.user.client.ui.Widget: like GWT2 itself, it was designed for a world which thankfully no longer exists: We no longer have a majority of browsers leaking memory just for daring to listen to events and change the dom. The whole "sinkEvents"/"sinkBitlessEvent", root panel with attach/detach cycle, and the __listener property to hook into all of it can go away, and we can freely mix dom elements and "widgets" without risk of leaking memory even after the tab is closed.

Removing all of that mean that some protected methods (that may be used for other things) would stop getting called in certain cases. Many downstream classes rely on that method, so something like the webcomponent lifecycle would need to be plugged in here to interoperate cleanly when added to a non-widget parent. It isn't a simple problem, but either we bring Widget in all of its bloated glory to GWT3 (after porting all of the JSNI...), or we redesign it from the bottom up, along with the ecosystem of classes which rely on it. I'm not yet sure which is better, and haven't heard a lot of people tackle this issue yet.

We are working on an aspect of this right now - it appears the sourcemap spec supports parameters and local variable renaming (though I'm less sure about field renaming) so that the debugger can correctly get the JS value that corresponds to the java name you are highlighting. One possible problem will be scoping - in JS, this.name and name are different, and I'm not sure how the browser debugger will know the difference, but at least it might work better in your console? worth looking into more.

Expressions on the other hand are not as simple, at least not in GWT2 - the entire expression must be compiled into JS, and the process that does this must already know how all of the other java was renamed. I don't think this is something sdm can presently do, and I'm also not sure that the browser debugger or the sourcemap spec knows how to pass that back and forth correctly... All worth exploring though.

I am experimenting both with IntelliJ and Eclipse. I use maven so far for my projects - it is very well supported by the IDEs and their tooling. In Eclipse you need to add the m2e-apt plugin, but IntelliJ comes with all of the pieces it needs already. Eclipse has a bug or quirk that makes it difficult to edit processors in the same workspace that you are running them in, and IntelliJ has a bug that prevents even external processors from correctly knowing when to rerun, causing some build issues from time to time.

In maven, the maven-compiler-plugin seems to have advanced far enough in version 3.5.1 that no other mojos are required to make it go.

https://immutables.github.io/apt.html gives some helpful steps to get either IDE running on a maven project with external processors.

https://github.com/Vertispan/aptexample is a demo example I built last week to try very simple processors in each IDE.

https://youtrack.jetbrains.com/issue/IDEA-179014 is a bug I filed against IntelliJ to improve their incremental rebuild.

I am looking to explore migrating to gradle, but I do like the long-term stability offered by Java, GWT, and Maven, even if they aren't necessarily each the most expressive or the coolest tools. I have been convinced by colleagues to give Gradle a shot, that it has stabilized enough.

A great question... and one I intend to discuss on day two of the conference in my talk "In Defense of GWT-RPC"!

A group of us started a localization tool in APT as a group back at the last GWT.create, but no one (myself included) has updated it since then. https://github.com/niloc132/i18n-redux. I'd love for some of us to put our heads together this year at GwtCon and keep this sort of thing going.

Frank Hossfeld started an Editor Framework processor, and I assisted in getting it going - it doesn't report errors very nicely yet, and requires a small change to how you build your drivers, but seems to work otherwise so far - suggest using this branch, we havent done a release yet https://github.com/niloc132/gwt-editor-apt/tree/model-first.

Elemento is a Elemental2-based templating tool https://github.com/hal/elemento, though I also made a SafeHtmlTemplates processor (this was before I knew much about processors - I would do it slightly differently now, and should take some time to update it) - https://github.com/niloc132/gwt-safehtml-templates.

Thomas Broyer built a GWT Places processor https://github.com/tbroyer/gwt-places.

And of course, Gin/Guice can be replaced by Dagger2.