[ https://issues.apache.org/jira/browse/PIVOT-1047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097718#comment-17097718 ]
Roger Lee Whitcomb commented on PIVOT-1047: ------------------------------------------- Did the same thing for Sheet*Listener: Sending wtk/src/org/apache/pivot/wtk/SheetCloseListener.java Sending wtk/src/org/apache/pivot/wtk/SheetStateListener.java Transmitting file data ..done Committing transaction... Committed revision 1877272. > Make sure that as many listener interfaces as possible can be used with > lambdas > ------------------------------------------------------------------------------- > > Key: PIVOT-1047 > URL: https://issues.apache.org/jira/browse/PIVOT-1047 > Project: Pivot > Issue Type: Improvement > Components: core, wtk, wtk-terra > Reporter: Roger Lee Whitcomb > Assignee: Roger Lee Whitcomb > Priority: Major > Fix For: 2.1.0 > > > Earlier we had (for Java 8 compatibility) made most/all interfaces implement > default methods so that the Adapter classes could be deprecated. But in > working with these, it appears that defaulting ALL the methods makes them > unusable as lambdas. > For instance, DialogCloseListener has just one interface method, perfect for > a lambda, except with default it isn't eligible. By simply making it pure > abstract there are no negative consequences, and makes it much more useful. > By this I mean, with only one method, the only reason to instantiate one > would be to implement the one, so "default" doesn't really make sense, while > abstract/lambda is perfect. > Investigate this for other interfaces, as some are more problematic, such as > TextInputContentListener, which has multiple "useful" methods, so the trick > would be picking just one (the most commonly implemented one?) to make > abstract. Or ListButtonSelectionListener which has two roughly equally useful > methods, where we would typically use one or the other, but not both. So, > making it lambda-compatible doesn't really help much, in terms of usability. > Others such as Validator are already abstract and need no change, except they > could be marked with the @FunctionalInterface annotation to make this clear. > Careful investigation is needed, since it is possible that making one method > abstract means the Adapter class might not be suitable for Deprecation > anymore either; not sure. -- This message was sent by Atlassian Jira (v8.3.4#803005)