The issue is that @JsFunction implementors must "extend java.lang.Object" as their parent. because standard library functions are/canbe implemented on classes with complicated type hierarchies, this would cause failures to compile.
This restriction comes about from the efficiency trick we use to reparent a lambda to have the native JS Function object as it's parent. We can't reparent objects whose immediate supertype isn't java.lang.Object, but not doing this trick would make output more bloated/slow, and wouldn't allow Java8 lambas to act like JS functions (e.g. can call Function.bind/apply/etc on them) without some kind of wrapping/unwrapping process, plus an additional level of hacks to make sure referential integrity was preserved. On Wed, May 11, 2016 at 5:51 PM, Colin Alworth <niloc...@gmail.com> wrote: > No, its not a solution, so much as a "here is a workaround that might > satisfy your specific case as you build your JsInterop-based lib so that it > looks like it can use @FunctionalInterface types". I do not believe it to be > a comprehensive way to provide the feature requested. At some point I'll try > to write it out in more detail in case there is any actual merit to it (I'm > all but sure that there isn't, or you would have thought of it already). > > On Wed, May 11, 2016 at 7:47 PM 'Goktug Gokdogan' via GWT Contributors > <google-web-toolkit-contributors@googlegroups.com> wrote: >> >> We cannot impose @JsFunction restrictions on standard library >> @FunctionInterfaces. You can see some of the limitations in the Javadoc. >> >> @Colin: I didn't understand your solution. Feel free to propose something >> more concrete and we can discuss over that. >> >> On Wed, May 11, 2016 at 4:22 PM, Colin Alworth <niloc...@gmail.com> wrote: >>> >>> Unfortunately, you can't add the annotation to an interface with more >>> than one method, even if those methods are default methods, at least as it >>> is currently implemented. >>> >>> I can't remember the exact specifics around why this is the case, but >>> believe it has to do with handling functions passed from js into java, and >>> not being able to nicely handle instances that decide to override those >>> other methods as well. >>> >>> You could nearly achieve this effect by just making a method reference to >>> the "apply" or "test" method, and passing that as an actual JsFunction type. >>> I don't right away see a problem with syntactic sugar doing this >>> automatically, but am sure that someone will be able to enlighten us as to >>> what confusing side effects this might have (or alternately confirm that >>> this is a great idea, and point to where in the compiler the changes need to >>> be made). >>> >>> >>> On Wed, May 11, 2016, 6:15 PM David Becker <david.bec...@sencha.com> >>> wrote: >>>> >>>> I think it would be good to add @JsFunction to all of the >>>> java.util.function interfaces in the JRE Emulation so that we can use >>>> standard function signatures with JsInterop. >>>> >>>> Would that work? Any drawbacks? >>>> >>>> If you think that's a good idea, I can submit a patch. >>>> >>>> Thanks! >>>> >>>> -- >>>> 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/13df9bed-108f-4cdf-8c00-123f1186e461%40googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>> >>> -- >>> 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/CADcXZMzaxRmFrvZUkQMG0VQETyJo5TWmjtFqPsn3msrBBvvLGg%40mail.gmail.com. >>> >>> >>> For more options, visit https://groups.google.com/d/optout. >> >> -- >> 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/CAN%3DyUA0CktOO8rpggbAcfPyTPhP7bp3fOTZgxSZiWyGq09waBw%40mail.gmail.com. >> For more options, visit https://groups.google.com/d/optout. > > -- > 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/CADcXZMwvRokmP5nq84jmE40Dmos3eMmPDH-V4RcCz-%2BjbubvxQ%40mail.gmail.com. > > For more options, visit https://groups.google.com/d/optout. -- 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/CAPVRV7fHWqxfPUE3-_JhLZiv0HJtUguCxqVxQQtpg2J52Z5%2BiQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
