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 [email protected]. 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.
