No-reflection might be overstated from the GWT perspective.  The first purpose of this change is to allow us to not do the heavy-reflection for the android case, though I did have in mind the GWT case in the long-run.

The classloading plugin itself does class-loading and newInstance() however the generated adapters themselves don't - they use "new Foo()" and the like.  I'm not a native-speaker of GWT, but was imagining an alternative loader plugin that loaded using GWT mechanisms.  The generated plugins idea has some possible punch - and could be done with an entirely separate processor. 

The key issue here is classloading, which seems like it can't be done at runtime in any way.  I worry however that we would need either a plugin for every adapter that can be found, or we would need a plugin that knew about all the adapters that are findable.  Quite simply, the deferred linking is where we get screwed here, because we don't initialize (or classload) until later to avoid the hit on android.  But we might need compile-time linking for GWT.  This is possible.  We could use an alternate linker, for example, but there are some issues that I see with our current design that are going to be hard for the gwt case.  Not insoluble, but still tricky.