Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Google Summer of Code 2015/JDT UI Code Completion and Refactoring"
| Line 33: | Line 33: | ||
=== Implementation Plan === | === Implementation Plan === | ||
| − | + | Java code completion is implemented in org.eclipse.jdt.internal.codeassist.CompletionEngine. This class relies on the matching functions implemented in org.eclipse.jdt.core.compiler.CharOperation. The main matching logic should be thus implemented in the latter class. However, the new code completion logic should not be made the default behavior, allowing users to choose, what kind of code completion they prefer. Currently, camel case completion is supported besides the simple prefix match completion and it can be switched on or off on the preferences dialog page with a checkbox. The suggestions that the new completion logic offers will be a superset of the camel case logic. Because of this, the aforementioned checkbox will be replaced by three radio buttons that allow choosing among simple completion, camel case completion and extended completion. | |
| − | + | The search functionality of JDT is not used directly by code completion but its functionality is analogous and the underlying CharOperation and StringOperation classes are also used here. Because of this, it seems useful to provide a new search flag that retrieves the same results as the new code completion logic. Search-related code is located in the org.eclipse.jdt.internal.core.search package of JDT Core. This subsystem is accessed through the BasicSearchEngine class. Its methods take a SearchPattern instance that describes, what has to be exactly matched. Several subtasks of matching and indexing are delegated to SearchParticipant, JavaSearchParticipant and org.eclipse.jdt.internal.core.search.matching.MatchLocator. However, the flags that control how the matching is done and the logic that decides whether a given name is matching, resides in SearchPattern. Thus, the implementation of substring matching requires the following steps to complete: | |
| − | # Implement | + | |
| − | # | + | # <strike>Implement the configuration controls in Preferences/Java/Editor/Content Assist for the new code completion logic</strike> |
| + | # Implement basic matching logic in CharOperation and StringOperation | ||
| + | # <strike>Extend the CompletionEngine class to use the new logic</strike> | ||
| + | # <strike>Implement the new search flag</strike> | ||
# Provide tests | # Provide tests | ||
| + | # Review, clean up and submit a patch | ||
== Details on Tail Completion completion == | == Details on Tail Completion completion == | ||
Revision as of 04:19, 5 June 2015
Contents
Contact
gabor at_sign kovesdan dot_here org
Project Goals
- Exploring current refactoring features of JDT UI, especially those related to Java 8 and extend its functionality with new features. For example: refactoring to Optional<T>, using String.join instead of StringBuffer, new Date API etc.
- Implement a simplified substring code completion. Only a small subset of substring matching will be implemented, which are useful to be an integral part of JDT UI. For example, .SelectionListener should match .addSelectionListener but not .addSelectionTestListener or .SL should match .addSelectionListener and .setSelectionListener but not .addSelectionTestListener.
- Implement postfix code completion. It increases developer productivity by reducing the need to jump back in the code. Often we start to type variable or type names and then we realize we have to go back to put a specific keyword before, such as if or throw. A demo about the concept is available [1] Also, there is some work done towards this feature. I propose reviewing and integrating this to JDT.
General TODO
Create wiki for GSOC
Introduction mail to JDT UI list
Clone JDT UI at Github
Sign CLA
Configure my workspace for the work, including Gerrit setup
Details on Substring completion
Matching Rule
- If the pattern only contains lower case letters, any member that contains the pattern as a substring is matched.
- If the pattern contains upper case letters, the list of matches is equivalent of the matches of the regular expression that is constructed in the following way. Before each upper case letter, \p{javaLowerCase}* is inserted, that is, an arbitrary number of lower case letters are allowed.
Implementation Plan
Java code completion is implemented in org.eclipse.jdt.internal.codeassist.CompletionEngine. This class relies on the matching functions implemented in org.eclipse.jdt.core.compiler.CharOperation. The main matching logic should be thus implemented in the latter class. However, the new code completion logic should not be made the default behavior, allowing users to choose, what kind of code completion they prefer. Currently, camel case completion is supported besides the simple prefix match completion and it can be switched on or off on the preferences dialog page with a checkbox. The suggestions that the new completion logic offers will be a superset of the camel case logic. Because of this, the aforementioned checkbox will be replaced by three radio buttons that allow choosing among simple completion, camel case completion and extended completion.
The search functionality of JDT is not used directly by code completion but its functionality is analogous and the underlying CharOperation and StringOperation classes are also used here. Because of this, it seems useful to provide a new search flag that retrieves the same results as the new code completion logic. Search-related code is located in the org.eclipse.jdt.internal.core.search package of JDT Core. This subsystem is accessed through the BasicSearchEngine class. Its methods take a SearchPattern instance that describes, what has to be exactly matched. Several subtasks of matching and indexing are delegated to SearchParticipant, JavaSearchParticipant and org.eclipse.jdt.internal.core.search.matching.MatchLocator. However, the flags that control how the matching is done and the logic that decides whether a given name is matching, resides in SearchPattern. Thus, the implementation of substring matching requires the following steps to complete:
-
Implement the configuration controls in Preferences/Java/Editor/Content Assist for the new code completion logic - Implement basic matching logic in CharOperation and StringOperation
-
Extend the CompletionEngine class to use the new logic -
Implement the new search flag - Provide tests
- Review, clean up and submit a patch
Details on Tail Completion completion
We have already a partial contribution for this to JDT, see https://github.com/trylimits/Eclipse-Postfix-Code-Completion https://git.eclipse.org/r/#/c/40855/
Details on Refactoring
Resources on Raffi's page: https://openlab.citytech.cuny.edu/khatchad/research/background/