[ https://issues.apache.org/jira/browse/GEODE-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15762780#comment-15762780 ]
ASF GitHub Bot commented on GEODE-1577: --------------------------------------- Github user metatype commented on a diff in the pull request: https://github.com/apache/geode/pull/321#discussion_r93150247 --- Diff: geode-core/src/main/java/org/apache/geode/distributed/internal/deadlock/GemFireDeadlockDetector.java --- @@ -97,7 +97,7 @@ public void clearResults() { ((AbstractExecution) execution).setIgnoreDepartedMembers(true); collector = (ResultCollector<HashSet<Dependency>, Serializable>) execution --- End diff -- You can remove the cast here as you've done in the other places. > Unhelpful generic types on Execution.execute > -------------------------------------------- > > Key: GEODE-1577 > URL: https://issues.apache.org/jira/browse/GEODE-1577 > Project: Geode > Issue Type: Bug > Components: functions > Reporter: Dan Smith > Assignee: Alyssa Kim > Labels: starter > > The execute methods of the function service Execution class returns a > ResultCollector with wildcards for the type. > {code} > public ResultCollector<?, ?> execute( > Function function) throws FunctionException; > {code} > Wildcards are supposed to be used in APIs where the type doesn't matter, for > example counting the elements in a list. By returning a ResultCollector with > wildcards, we're essentially forcing the user to cast the result collector. > At a minimum they should be able to pick the type of result collector > {code} > public <T,S> ResultCollector<T, S> execute( > Function function) throws FunctionException; > {code} > But maybe it would make more sense to parameterize Execution itself. Then the > compiler could ensure that the types used by withCollector and the types used > by execute match. -- This message was sent by Atlassian JIRA (v6.3.4#6332)