OK, so I uploaded 3 changes: https://gwt-review.googlesource.com/15420 The first one (linked above) fixes the regression by special-casing j.u.Iterator; this is clearly a hack, we may miss other cases and other (third-party) generators may be impacted as well. The second one adds getAllMethods / getAllOverloads / getAllInheritableMethos / getAllOverridableMethods to JClassType that return the Java 8 methods (static and default) for interfaces. I started with overloads taking a boolean argument but found new/separate methods to be easier. The third commit replaces the hack in AutoBean with a proper fix using the new API.
On Wednesday, July 13, 2016 at 8:15:57 PM UTC+2, Roberto Lublinerman wrote: > > For the short term I think we should handle this by a fix in autobeans. > For the long term we could introduce a version of getMethods(flag) that > allows to specify which methods you want and the parameterless version > defaults to Java 7 behaviour. > > On Wednesday, July 13, 2016 at 7:37:00 AM UTC-7, Thomas Broyer wrote: >> >> +cc Colin, Goktug >> >> On Tuesday, July 12, 2016 at 12:48:58 PM UTC+2, Ross Drever wrote: >>> >>> Calling remove on an iterator from list within an request factory entity >>> proxy results in an UnsupportedOperationException. >>> >>> I have isolated it to commit 288cc03 Hide Java 8 interfaces methods to >>> generators. If I revert that commit it works properly. Seems like it is >>> picking up the wrong implementation of iterator.remove() when it generates >>> the proxies. >>> >>> >>> Iterator<SomeProxy> iterator = someEntityProxy.getSomeList().iterator(); >>> iterator.next(); >>> iterator.remove(); //throws UnsupportedOperationException >>> >>> >> Ah right; this is "actually" because Iterator#remove *became* a `default` >> method in Java 8: >> >> https://docs.oracle.com/javase/7/docs/api/java/util/Iterator.html#remove%28%29 >> >> vs. >> https://docs.oracle.com/javase/8/docs/api/java/util/Iterator.html#remove-- >> Really not sure what would be the best outcome here; but I think we need >> to re-investigate this decision of *hiding* default methods to generators, >> as there might be other similar cases either in the JDK or in third-party >> libs moving to Java 8. >> In the short-term, we may want to maybe add an annotation to ask GWT to >> expose a `default` method as if it were 'abstract', only for >> backwards-compatibility for cases like this. >> For AutoBeans specifically, one possibility would be to *not* generate >> the IteratorAutoBean and instead provide one that implements the remove() >> method; or to special-case java.util.Iterator to have the generated shim >> extend a provided base class. >> In the medium/long-term, AutoBeans would probably be rewritten as an >> annotation processor anyway (which could also unify the JVM vs. GWT >> implementations, instead of using java.lang.reflect.Proxy in the JVM). >> > -- 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/ea60e4d7-7618-4a3a-a7e3-20cdb03c72a6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
