[
https://issues.apache.org/jira/browse/GEODE-6884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16866072#comment-16866072
]
Joris Melchior commented on GEODE-6884:
---------------------------------------
Yes, there are issues with the fix we provided. I clearly should not have
rushed this and taken a step back. Will have to roll that back.
> Execution.withFilter() and friends introduce type parameters inconsistent
> with class' type parameters
> -----------------------------------------------------------------------------------------------------
>
> Key: GEODE-6884
> URL: https://issues.apache.org/jira/browse/GEODE-6884
> Project: Geode
> Issue Type: Bug
> Reporter: Bill Burcham
> Priority: Major
>
> A recent change to {{Execution}} changed {{withFilter()}} and friends so they
> introduce their own type parameters:
> {code:java}
> <ArgumentT, ReturnT, AggregatorT> Execution<ArgumentT, ReturnT,
> AggregatorT> withFilter(
> Set<?> filter);
> {code}
> This eliminates a compile error over in {{FunctionRetryTestBase}} where
> chaining was happening:
> {code:java}
> final Execution<Integer, Long, List<Long>> execution;
> switch (executionTarget) {
> case REGION:
> execution =
>
> FunctionService.onRegion(clusterStartupRule.getClientCache().getRegion(regionName))
> .setArguments(200);
> {code}
> Unfortunately though, this change introduces a "hole" in the typing so that
> the client (of {{Execution}}) is able to produce instances parameterized on
> arbitrary types. The compiler is happy with just about anything, but runtime
> exceptions ({{ClassCastException}}) will ensue.
> Here is an example of code that compiles
> [https://gist.github.com/Bill/5e2ad2ba4b60461dd0af8adfa4adc91b:]
> {code:java}
> final Execution<String, String, String> execution =
> FunctionService.onRegion(null);
>
> //Add a string argument, which appears to be typesafe
> final Execution<String, String, String> addedArgument =
> execution.setArguments("hello");
> //But wait! If we call withFilter, we get to change the type of Execution
> with no warning
> //or casts. We won't see the class cast exceptions until runtime.
> final Execution<Integer, Integer, Integer> execution1 =
> execution.withFilter(Collections.singleton(5));
> {code}
>
> A hint at the problem is that IntelliJ inspections highlights the new type
> parameters on e.g. the {{withFilter()}} method indicating that the type
> parameters on the method are hiding the type parameters on the class. This is
> an indication that even though the names are the same—the type parameters to
> the method are completely different from the ones on the class. There is no
> enforced correspondence. The compiler gives you complete freedom here.
>
> !image-2019-06-17-16-11-39-678.png!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
