Community
Participate
Working Groups
The search engine should support a new 'limitTo' option in IJavaSearchConstants to limit matches to Java-8-style method reference expressions. E.g. only one reference to Integer#toHexString(int) should be found in this code when the flag is set: Function<Integer, String> hexer= Integer::toHexString; // yep System.out.println(hexer.apply(666)); System.out.println(Integer.toHexString(666)); // nope
This would be good to have for 4.4
Please co-ordinate with the UI team for UI updates,
Manoj, this is requested by the UI team. Please work on this for M7
Created attachment 241272 [details] Proposed Patch
Dani, would we get approval for this API change coming in at M7 ? Otherwise we will have to move this out to 4.5. IMO, this is not critical, but Markus may differ. Manoj, please post the relevant portions of the API change including javadocs and such so people can form an informed judgement. Thanks.
/** * Return only Java 8 style method references, ie A::foo. * <p> * When this flag is set, only {@link MethodReferenceMatch} which are * java 8 method references will be returned. *</p> * @since 3.10 * @category limitTo */ int JAVA8_METHOD_REFERENCE = 0x10000000; This is the new category that is added to the search pattern. Strictly from an API point of view, there are no additional methods that are requested for. Would we need an approval for this?
(In reply to Manoj Palat from comment #6) > /** > * Return only Java 8 style method references, ie A::foo. > * <p> > * When this flag is set, only {@link MethodReferenceMatch} which are > * java 8 method references will be returned. ^ ==> Java > This is the new category that is added to the search pattern. Strictly from > an API point of view, there are no additional methods that are requested > for. Would we need an approval for this? Any API changed needs approval after M6 (API freeze).
Here are some comments after a quick glance through the patch - I didn't review it yet: - It appears there aren't any tests that show only method references being selected and presented while other types of references to the target method are filtered ? - Include tests for different flavors of reference expressions. e.g: constructor references don't feature in the tests at all ? - JAVA8_METHOD_REFERENCE - I am not we should encode version number in the API ? did you see a precedence and chose this ?
Let's use this API: /** * Return only method reference expressions, e.g. <code>A::foo</code>. * <p> * When this flag is set, only {@link MethodReferenceMatch} matches will be * returned. *</p> * @since 3.10 * @category limitTo */ int METHOD_REFERENCE_EXPRESSION = 0x10000000; I agree the Java version shouldn't be part of the API name. The obvious "METHOD_REFERENCE" would indeed be problematic, since "reference" is already widely used. But the full name from JLS8 15.13 should work.
Created attachment 242142 [details] Proposed Patch - Thanks Srikanth and Markus for the suggestions - incorporated the same, and made current to the latest ToT. - API modified to as mentioned in comment 9
Patch looks good to me.
Released latest patch as http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=7cbfac0f262651a92552aa1b245acf5ef1db3bb0
Hmm, was too quick. The example for a constructor reference expression in org.eclipse.jdt.core.tests.model.JavaSearchBugs8Tests#testBug429012_0015() has various compile errors and doesn't test the interesting case where other matches could show up (but shouldn't). Here's a better example: import java.util.function.Supplier; /** * @see Y#Y() */ public class X { public static void main(String [] args) { Supplier<Y<String>> s = Y<String>::<Integer>new; s.get().equals(new Y<String>()); } } class Y<E> { <T> Y() { System.out.println("Y<E>::<T>new"); } } However, I somehow don't get any search result if I change the test to use this one.
Created attachment 242311 [details] Proposed Patch - part 2 Thanks Markus. Here is the proposed patch with the following additions: - incorporated Markus' testcase plus the solution for the issue. - Additional modifications done to test cases to show explicit filtering.
(In reply to Manoj Palat from comment #14) > Created attachment 242311 [details] [diff] > Proposed Patch - part 2 Looks good and works fine.
(In reply to Markus Keller from comment #15) > Looks good and works fine. Markus: Thanks for the review. Committed via : http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=bf2199048d434ee8a7461950468d3a2335a30990
Verified for 4.4 M7 with build I20140428-2000
