Have not read the whole thread yet, but just wanted to point out a few small things.
First, whole-world compilations and transforms are something I've been working on as a replacement for generator subsystem since I heard it was dying a couple years ago. I have a toy implementation working with java 8 javac compiler plugins, though it looks like that is going away now that java 9 modules exposes the compiler in a more powerful / official capacity (I have a commit w/ java 9 support already, btw). >From these experiments, I can conclude that it is possible to get typesafe whole-world analysis out of your standard javac process, and do ...anything you want. The whole-world part does involve forcing javac to reconsider referenced types, and so will be slower than standard javac... but it is, indeed possible. My main use cases were a GWT.create-like replacement; I have a prototype able to slurp up the class literals the same (or better) than stock GWT (I also run a fork of GWT 2.X that does other magic-method-magic), which can then run replacement rules that generate code (completely different AST, and no TypeOracle just yet, but all things are possible with time). I didn't bother w/ gwt.xml support yet, as it was just a toy to see if it was possible (it is). My other main use-case was a new ui-templating library to replace the need for ui binder; the solution I came up with includes a DSL that generates cross-platform view components for web and javafx... android and ios will likely get a kotlin target someday, but it could easily be stripped down to something that emits artifacts suitable for webpack et al. Both of these efforts have prototypes laying around that could be cleaned off if there was significant community interest, but it's hard to spend lots of time on these things when I've also got a day job and an infant at home :-) So, while I'm not promising I can magically deliver everything that will go missing overnight, it is possible, and there are other members of the community who are interested. However, to get production-ready support and testing, this would likely need to be a fulltime effort. *Do ye dissatisfied members of the community think it possible that support contracts for GWT 2.X and porting of features into GWT 3.X would be viable?* While I'm currently happily employed, I would certainly consider working on fulltime support for these replacements *if* it could occupy my working hours rather than my scant hours of rest. If your mission critical applications depend on keeping up to date with latest GWT versions but need older GWT features, well... somebody has to put in time, and it's not looking likely that it's going to come for free from community members' spare time. In reality though, existing applications can stay on 2.X for a long time, provided odd compiler bugs get worked out. While I can find a night here or there to fixup things like sysprops not generating permutations correctly (took about 5 hours work), I also have my own projects on top of work and GWT community and family, so I'm stretched pretty thin. PS -> I already maintain an open source fork of GWT which includes support for reflection and arbitrary magic method injection. I did not even try to get these merged upstream because they move in the opposite direction of GWT (I was going for more magic, and they for less); my long term game plan is to get my extra bells and whistles pulled into the javac plugin system (with my other prototypes in that area), so I can prefer J2CL as well. While I will get to this eventually, if there is enough motivation to pay to get to it in a hurry, I think there is enough willing talent to pull off ...whatever we want. :-) -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/9f7563ef-9774-4c86-b620-46bd6259f24a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
