Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.
This release adds subtype-aware code completion as well as constructor recommendations (as of this writing for JRE classes only) to content assist.
Moreover, this release significantly improves the performance of content assist, in particular when using subwords completion for types and constructors.
Another small, but notable change is that Code Recommenders code completion is enabled by default. The user will be notified of this fact when triggering content assist for the first time and can then choose to configure or deactivate Code Recommenders.
The project leadership certifies that the APIs in this release are "Eclipse Quality".
With Code Recommenders 2.0.0, the code base has seen a significant architectural redesign to cleanly separate UI from components useful in a headless environment. With the 2.2.0 release, the design has further evolved in this direction; in particular, the previous component for management of recommendation models has been split in two with clean-cut responsibilities: identification of dependencies and loading/caching of model artifacts.
- Code Recommenders uses Google Guice as its primary dependency injection mechanism; some extension have to be contributed using Guice Modules rather than using Eclipse extension points. In addition, Code Recommenders internally mixes Eclipse 4 and Google Guice DI for accessing preferences. For future releases we may investigate how to move from Guice to Eclipse 4 DI, but this would require a significant amount of work to be done in both Code Recommenders and E4 to support required concepts. This change is not yet on the roadmap for any future release.
- Code Recommenders uses Google Guava’s implementation of an EventBus instead of reusing Eclipse 4 IEventBroker. This is mainly because there was no reason to switch from Guava to the Eclipse implementation. This may change in future releases.
Code Recommenders does not handle personal information and does not share details about a user’s code with any entity on the web. Users should be aware, however, that by default Code Recommenders performs network I/O in the following cases:
- On start-up, Code Recommenders checks for updates of a model index file hosted on download.eclipse.org. If updates are available, a larger download (< 1 MB) is triggered.
- Whenever a library is accessed the first time, Code Recommenders checks for updates to the respective recommendation models hosted on download.eclipse.org. If updates are available, a larger download (up to several MB) is triggered. Both update checks and downloads may leak information about the libraries used by a developer. To prevent this, auto-download mode can be disabled; model archives can still be downloaded upon explicit user request.
- Code Recommenders has the ability to query Maven Central in order to identify a library used by the user. To do so, a cryptographic hash will be send to a server not hosted by the Eclipse Foundation. By default, this ability is not used; it must be explicitly enabled by the user.
- On start-up, the optional Snipmatch component pulls snippets from a Git repository hosted on git.eclipse.org.
- Due to its nature, Code Recommenders’ log messages often refer to portions of the user’s code. If the user makes use of the Eclipse’s Automated Error Reporting facility, he or she should take care to read and, if necessary, sanitize the error report before sending.
If the user works in a severely restricted environment with limited or no Internet connectivity, Code Recommenders and its recommendation models can be downloaded and installed at once. The project website provides instructions for this use case, which is expected to be rare, however.
By default, Code Recommenders uses no cryptography. However, recommendation models or snippets may be served of HTTPS if the remote server supports this.
- User Documentation: The current project website (online since December 2013) contains a short Getting Started guide, an extensive Manual, and a FAQ. The project website is linked to on the Welcome to Eclipse view shown after installation. Several subpages (manual, FAQ) are linked to from various places in the software (dialogs, preferences).
- Localization: As of Eclipse Kepler, Code Recommenders is fully internationalized and relies on the Eclipse Babel project for localization. Internationalized resource files have been made available to the Babel project from Code Recommenders 2.1.13 on (released 23 March 2014).
- Build system: Code Recommenders is build with Apache Maven and Eclipse Tycho. It makes some use of the Common Build Infrastructure (Gerrit, Hudson, signing webservice), but does not (yet) inherit from the CBI’s parent POM. To ease initial project setup, Code Recommenders uses Eclipse Oomph both for the main project and its incubator projects.
Developer Documentation and Code Examples:
Code snippets showcasing how to use the low-level headless APIs introduced with Code Recommenders 2.0.0 are kept with the source projects. They should provide sufficient information on how to integrate additional recommendation engines with Eclipse Code Recommenders or how to obtain recommendations using the headless API. This information has proven sufficient for implementing a proof-of-concept Netbeans port of Code Recommenders’s code completion.
Code Recommenders 2.2 is stable and designed for daily and frequent use. It should run without any issues in terms of performance or memory consumption on standard development machines.
That being said, much effort has been spend on improving the responsiveness of the UI during content assist. Several causes for UI freezes have been eliminated, resulting in a smoother user experience.
For a short while in the Code Recommenders 2.1.x line, an automated error reporting feature was shipped under the name Code Recommenders Error Reporting. This feature has since moved to the Eclipse Packaging Project.
The Code Recommenders projects interacts with its end users in various ways and places:
- Blog posts announcing new features of Code Recommenders occur infrequently. They are syndicated on Planet Eclipse.
- Short announcements are made on both a Google+ page and Twitter account. However, much of the communication happens over the project lead’s Google+ and Twitter accounts.
- The Eclipse Forum has never seen much traffic and is not not used anymore. There exists an external support forum, which receives light traffic (1-2 questions/month).
- Bugs and enhancements are tracked and discussed in Bugzilla.
- Code Recommenders also solicits feedback on Uservoice and Stackoverflow. These sites are advertised on the Code Recommenders preference page and the Code Recommenders website’s community page, respectively.
The Code Recommenders project interacts with both its adopters and developers/committers through the same set of channels:
- The project’s developer mailing list is the primary instrument for coordination among developers. The list receives about 25 mails/month during the Google Summer of Code season and 5-10 mails/month during the rest of the year.
- Planning and prioritizing decisions are noted in Bugzilla by assigning target versions to the individual issues.
- Contributions are accepted through Gerrit only. Part of the code review are automatic integration tests on the project’s Hudson instance (HIPP).
- Blog posts on technical topics surrounding Code Recommenders in particular and Eclipse/OSGi development in general are published infrequently and rarely. They are syndicated on Planet Eclipse.
- As part of the Google Summer of Code 2014, the project has attracted six student contributors. As part of the Google Summer of Code 2015, two students contribute to Code Recommenders or its incubator projects. One of the students in 2015 participated in 2014 already and is mentored by a prior GSoC participant. Reducing the number of mentored students in 2015 was a conscious decision of the project’s core committers based on the previous years’ experience.
Code Recommenders coordinates itself with four other Eclipse projects: JDT, Aether, m2, and Mylyn.
- Code Recommenders initiated one change to JDT (Bug 464552) that improved both the performance of JDT and (indirectly) Code Recommenders. Aside from that, the coordination between the project is mostly one-sided: JDT evolves and Code Recommenders adapts to it.
- As predicted during the Code Recommenders 2.1.0 release review, the coordination effort with the Aether and m2e projects has decreased in the past year. While both Code Recommenders and m2e depend on Eclipse Aether, Code Recommenders uses the artifacts supplied by the Aether project directly, whereas m2e uses a specially packaged artifact bundling Aether with various libraries from the Apache Maven project. As of this writing, the only known issue (rooted in Equinox) is Bug 465593, which affects users who install Code Recommenders, m2e and the (third-party) SonarQube plugin.
- Minimal coordination effort is required with the Eclipse Mylyn project, due to an (optional) integration of Eclipse Code Recommenders’ intelligent code completion engine with Eclipse Mylyn’s task-focussed UI. Since its release as part of Code Recommenders 2.0.7, this feature has required almost no maintenance effort.