A few issues have come up (both in my own projects and in the issue tracker) where it seemed that continuing to maintain and update the GWT Generator and Linker types may be necessary. At least one was fairly low-hanging fruit (up for review at https://gwt-review.googlesource.com/#/c/14750/), but Daniel raised an important question that should be discussed: What is happening with GWT 2.8 Generators and Linkers.
In general the philosophy seems to be a mix of "if unmaintained, we'll phase it out", and "If you keep it up to date, we won't go out of our way to break it". Specifically in this case however, we'd like to begin the process of phasing out Generators (in favor of APT for your code generation needs) and Linkers (in favor of J2CL and the Closure Compiler ability to emit JS code and artifacts). --- My *personal* position is that GWT 2.8 is set for long-term maintenance - we expect point releases to keep it functional for teams not ready to make a big shift right away, for a variety of reasons (while I'll leave out to keep this short). GWT 2.8 is meant to be a bridge release for apps that wish to have modern Java support and JsInterop types at their disposal, and as they ready themselves for GWT3/J2CL, they can continue to function and stay up to date. The future will only be available beyond 2.8 and Generators, but in the meantime, they shouldn't be second class. The specific requests here are for static and default methods in AutoBeans or RequestFactory Proxies/Contexts. My goal (as stated in the bug reports) is not to add new features where getters/setters have their behavior altered, or get hooks before/after changes are made, but to let these methods be populated and called without breaking the compilation process in surprising ways. AutoBeans already support Categories, a sort of externally defined method that seems purpose-built to be eventually replaced by default methods - thats my goal in my own work here, outside the specific filed issues. I expect other features will be made easier to use too, such as lambda'd RPC callbacks, safehtmltemplates with logic and loops, and On the other hand, if we have published documents ready on what APIs will be available easily for linking, or for generating i18n/locale/device permutations through the use of external resources or alternate sets of constants in compiled code, my ground for complaints is limited to merely pointing out the existing stable code that could be better before it is ready to be ported. I don't think that this is going to be a hard point to sell. --- So: in the spirit of always building better releases: Where does this argument go wrong? How much better off are we by shedding this weight now, and what great upgrade paths do we have? Is improving them but also marking them all as @Deprecated a good compromise? Please poke holes in this so that we can make GWT 2.8 an enduring release that is still able to be seen as a powerful tool for Java web developers! Thanks, Colin -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/5abbf455-d7a0-4d36-8b85-ee8a3118e734%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
