Community
Participate
Working Groups
public interface Foo { boolean equals(Object obj); } class X { void method1(){ Foo f = <ctrl-space> } } Since the place assist is called, has a functional interface with void parameter, it it should suggest something like '() -> {}: lambda expression'. This is the same way as possible methods are suggested.
Hello, Mistakenly wrong example pasted. Please ignore the example in the description. Please consider the following example. The problem statement, otherwise remain the same. public interface Foo { int run(); } class X { void method1(){ Foo f = <ctrl-space> } } Thanks Anirban
Why just a functional interface with a void parameter ? In fact it would be more useful in non-void cases. Markus, are you interested in supporting this feature ? If the target type in the expression context is a functional interface type, then there could be a quick assist. I primarily see this as UI side work, with perhaps core filling in on the target type details. Perhaps there could be a org.eclipse.jdt.core.CompletionContext.TL_FUNCTIONAL_TYPE_START and this information could be augmented with org.eclipse.jdt.core.CompletionContext.getExpectedTypesSignatures() (/keys) If you are interested, let us know the time frame.
As with everything else with Java8, there could be a number of complications around overload resolution. We can consider every potential method as a candidate and use argument positional information to compute the set of expected types.
Fixing bug summary. This is not for Quick Fix / Ctrl+1, but for Content Assist / Ctrl+Space. We should already have anonymous class creation proposals in these places, so I'm not sure what additional infrastructure JDT Text (Dani) needs.
This should also work in places where the expected type is defined by the context. E.g. for method arguments. At |, I'd expect lambda proposals for FileFilter as well as for FilenameFilter: void foo(File folder) { for (File file : folder.listFiles(|)) { System.out.println(file); } } The lambda proposals should show up without a prefix and maybe also with a "->" as prefix. The latter would be necessary in case the lambda proposals don't get the highest relevance. The additional info for the lambda proposals should show the Javadoc of the functional interface method.
(In reply to Markus Keller from comment #4) > We should already have anonymous class creation proposals in these places, > so I'm not sure what additional infrastructure JDT Text (Dani) needs. If I just press Ctrl+space at the locations specified in examples of comment #1 and comment #5, I do not get the proposals for creating anonymous inner types. I get those only when there is "new " as prefix while pressing Ctrl+space. However, for lambda creations, content assist should work without any prefix or with "->" as prefix as mentioned in comment #5.
*** Bug 458319 has been marked as a duplicate of this bug. ***
Bug 443091 has been reported for support from JDT/Core.
Any updates?
Is this planned for the 2016 release?
(In reply to Serhiy from comment #10) > Is this planned for the 2016 release? No.
(In reply to Dani Megert from comment #11) > (In reply to Serhiy from comment #10) > > Is this planned for the 2016 release? > > No. Sad. I realize that development team is very limited but still it is very sad to not have this for so many years. Can you provide any entry point (docs and examples) how a person not familiar with Eclipse JDT development can try to start working on this issue?
Just wanted to add that few days ago I have tried daily build of NetBeans and they have this feature implemented. Works nicely in NetBeans (event better than this feature is implemented in IDEA). So I would say that from my personal point of view daily build of NetBeans can be used as a good example of how such feature needs to work. So really hope it will get into 4.7. Thanks, Serhiy
This would be EXTREMELY useful. I also created bug 527104 (could not find this), because other contexts completions/code templates would be useful (for Optionals, for instance).
(In reply to Noopur Gupta from comment #8) > Bug 443091 has been reported for support from JDT/Core. Removing the target milestone. It can be re-assigned when the core support is available.
Gayan, can you have a look?
Sure i can add it in 4.20 release
Gayan, can this bug be marked as fixed?
Yes i think this is also covered in https://bugs.eclipse.org/bugs/show_bug.cgi?id=443091
*** This bug has been marked as a duplicate of bug 443091 ***
