My responses to specific points: Removing JSNI, <replace-with>, generators... we ourselves were careful enough to either never use some of these and/or to abstract and encapsulate their use. However everyone here seems to take the perspective of "it is just one product of one company that is affected". It isn't. Some of us have our customers who develop additions too. Even if we have code to clean up and clean it up, it still renders the solution incompatible with add-ons created by others. There is *no* migration here. Customer buys a foundation (A) from one company and add-ons (B) and (C) from two other companies. They then upgrade (A) to (A2) and suddenly (B) and (C) don't work. They cannot and won't just ask for new (B) and (C) - this may not be possible for business or technical reasons. Migration is not a model at all. It is a complete breakage.
GWT RPC itself has a lot of problems but the central part of it that cannot be done efficiently outside the core compiler without hooks made specifically for this is the serialization of restricted-visibility fields of classes made by third parties. Yes, it could be addressed by uet another preprocessor but why-oh-why do this? TeaVM does not do this but allows for it to be made using Metaprogramming API. Otherwise, serialization-related analysis of GWT is presently horribly inefficient and *can* be done really well - it does NOT need to be slow like some were saying., It is slow with the current design - that much is certainly true. Whitelisting (yes) and annotations are valid approaches. For example, w/o better approaches one could use *.gwt.xml to whitelist if not do it from annotations (which would be better). This really does not need to take significant time at all. I am a little thin on UiBinder... can't talk much about it other than, perhaps, also provide ways for this to be optional and a separate module during compilation. ClientBundle - whatever it is or isn't, it was a way to encapsulate styles in widgets and do other things. See my comment on migration not being a model for large cases. Being able to access resources is a part of Java, one way or another ... and this would form yet another thing that wasn't quite Java but is close... and is getting lost too. Re: "First, GWT 2.x is not dead yet or for the foreseeable future."... How's that? Maybe it isn't dead but it seems to be on deathbed, with very little life support and no (communicated) vision of future at all. All we have is that it isn't GWT 3 and that GWT 3 is significantly less than GWT 2 but with J2CL and somewhat better JavaScript interop that may or not be important. Re: "Do you have the slightest idea what amount of work that represents?! Given that Google won't do it (on their own dime), it'd be highly unlikely that it'd be free or even opensource." ... Yes, I actually do. Do you have any idea how much work that would save? I don't need a solution that does not reduce my work. GWT 3 increases that work. With respect to free/opensource - I can't comment on that as I can't predict future but I tend to agree for other reasons. Otherwise, there are much more complex open source and free solutions oht there. Some are funded by the sponsor companies who they benefit, some aren't but there is a set up guidance. You say "Incidentally, you've had 2 years to start planning for it..." but that is not really the case as there was this illusion that there existed a body that actually cares about what happens to existing users *OR* GWT 3 in general. At the same time there were announcements that 2.x will continue and that there is a steering committee, so there were hopes that it will realize the importance of things being dropped. Incomplete, unclear and downright misleading communication and ignorance of current users brought us here. Sure enough, I agree that Google does not need to foot the bill for this if it doesn't care, but I would have appreciated some more honesty. -- 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/53de52e6-5bf0-4d9e-8cdd-a73b39631bb2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
