Community
Participate
Working Groups
I have the following example and I'd like to know if the current JDT behaviour is fine. Using Eclipse Neon.3 (4.6.3) with JDT 3.12.3.v20170301-0400. public class TestLambda { public static void main(String[] args) throws InterruptedException { final List<String> strings = Arrays.asList("a", "b", "c", "d", "e", "f"); final List<Callable<Void>> callables = strings.stream().map(new Function<String, Callable<Void>>() { @Override public Callable<Void> apply(final String s) { return new Callable<Void>() { @Override public Void call() throws Exception { System.out.println(s); return null; } }; } }).collect(Collectors.toList()); Executors.newFixedThreadPool(2).invokeAll(callables); } } If I convert new Function<>(){...} to lambda expression, with Ctrl+1, I get: public class TestLambda { public static void main(String[] args) throws InterruptedException { final List<String> strings = Arrays.asList("a", "b", "c", "d", "e", "f"); final List<Callable<Void>> callables = strings.stream().map(s -> new Callable<Void>() { @Override public Void call() throws Exception { System.out.println(s); return null; } }).collect(Collectors.toList()); Executors.newFixedThreadPool(2).invokeAll(callables); } } But JDT complains: Type mismatch: cannot convert from List<Object> to List<Callable<Void>>. If I roll back and then do the following: - Ctrl+1 on new Callable<Voide>(){...} to convert to lambda expression - Cltr+1 on new Function<>(){...} to convert to lambda expression I get: public class TestLambda { public static void main(String[] args) throws InterruptedException { final List<String> strings = Arrays.asList("a", "b", "c", "d", "e", "f"); final List<Callable<Void>> callables = strings.stream().map(s -> () -> { System.out.println(s); return null; }).collect(Collectors.toList()); Executors.newFixedThreadPool(2).invokeAll(callables); } } But then JDT complains twice: - The target type of this expression must be a functional interface - Cannot infer type argument(s) for <R> map(Function<? super T,? extends R>) The latter problem may be a consequence of the former, but I'm not sure.
Are you questioning the compiler or the quick assist (Ctrl+1)?
Good question... The quick assist seems to produce valid code, but I don't know if in this specific case it should add more type information, perhaps on the lambda input parameters? Or, either, the compiler is complaining while it should not. The net result is that I would not have expected to see compilation errors when switching from one form (anonymous inner classes) to the other (lambda expressions), otherwise probably the quick assist should prevent me from doing this.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.