I agree entirely, just trying to see this as a potential contributor with its associated steep learning curve, and address the question of "Should we stop adding new features?".
we're rather in a situation of "I'd like to add this new feature to GWT; > and this is something I could do in my own code" If (and I stress *if*) we are prepared to stop accepting features requests *that come with technically correct code*, we should not make that decision lightly. There is little doubt that this would be an improvement to GWT, and something that generally would make GWT apps better - why should we not take it? My (and your) alternative of using an external safe-* project adds boilerplate for using gwt-user features that are considered up-to-date and well supported. That is the main basis for my +1, that it isn't sufficient to say "well, if you want this browser API, which could be easily supported out of the box, here are the hoops you jump through". Find/Replace all use of UriUtils leads to prefixed MyCompanyUriUtils for each class in the GWT that could/should be better, and does make updating harder, or encourages forked copies of GWT which then can be difficult to rebase and keep up to date. In contrast, transforming a user into a contributor, even if only a fraction of them stay with us long term, improves the overall health of the project. The one technical objection I see is that including Collections.emptySet() and its transitive tree might add some weight for small projects that avoid *any* java collections. String[] might be preferred, but with a minor runtime cost last I checked. If it is a technically bad patch (style, increases compile time/size in an unacceptable way, insufficiently tested/documented, insecure, etc), it should be rejected. If it *could* be done in user code (and just about any feature request *could* be done), this probably isn't enough to reject it, unless we think it is a fringe case which other users are unlikely to avail themselves of. But if it improves the sdk in a way that will benefit users, and make it clear that GWT is in it for the long haul, improving every release, and open to developer contributions? Why should we stand in the way of that? (Again, mostly devil's advocate, trying to address the huge number of concerns we've had over the last year or four of "contributing to GWT is too hard" or "GWT doesn't move forward and stay current with modern APIs". This is a token changeset to address this, and probably not perfect to demonstrate these thoughts, but I just wanted to make the point that we will be sending a message *whichever direction we take* with this changeset.) -- 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/39713959-c162-47af-b6d3-803e9c5fe736%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
