2.0.0
Code Recommenders 2.0 major goal is to provide a headless API that allows extenders to build new tools on top of Recommenders. Second goal is the development of a new completion engine API on top of JDT that allows to integrate existing completion engines (call, override, chain, subwords, templates) into a single completion engine and over all improves the user experience.
Additional features planned for 2.0 are a crowd-sourced code snippet store, an integration of Code Recommenders into the Javadoc Generator, and a developer activity report module. These modules are in Recommenders incubator. They are not officially part of Recommenders 2.0.
The project leadership certifies that the APIs in this release are "Eclipse Quality".
In the 2.0 release, Code Recommenders was subject to a comprehensive architectural redesign. With Code Recommenders 2.0, clients can now built their own recommender systems in and for Eclipse but may also run Code Recommenders' technology outside Eclipse, e.g., in headless environments or their own applications. One successful application of this is found in the Livedoc project in the Code Recommenders incubator, which uses the Code Recommenders’ technology as part of Javadoc creation.
Where appropriate Recommenders follows a two-tier architecture. The lower, headless layer is build on plain Java; it does not rely on Eclipse APIs and can furthermore be used outside of an OSGi environment. The upper, Eclipse-dependent layer provides full integration into the Eclipse IDE.
The Eclipse-dependent layer makes use of competing technologies, extenders should be aware of. For instance, Code Recommenders heavily uses Google Guice as DI framework. 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. It’s not yet on the roadmap for any future release.
Surrounding the use of DI, we recently encountered an versioning issue with the javax.annotation bundle exported both (without version constraints) by the core org.eclipse.osgi bundle and with version constrains by a bundle from Orbit. We found that this increases the risk of uses conflicts.
Code Recommenders also 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.
The architecture for 2.0 is well-designed for the known use-cases. The team did its best to provide a reusable set of libraries that can be used outside of the Eclipse IDE or in absence of an OSGi framework. Prototypes like the Livedoc Javadoc generator mentioned above have been designed to prove reusability. Also, others have started to contribute a Code Recommenders integrations into Netbeans. We hence assume that the provided libraries satisfy the known needs. In the case your use case cannot be implemented with the current design, let us know.
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 Code Recommenders (i) automatically downloads a model index file from eclipse.org on startup and (ii) in auto-download mode it automatically fetches recommendation model archives whenever a library is accessed the first time. This 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. By default, Code Recommenders does not use cryptography.
However, model archives may be served of HTTPS if the remote server supports this.
Internationalization: As of Eclipse Kepler, Code Recommenders uses externalized UI messages and cooperates with the Babel project to localize said messages. Translations, however, still need to be updated for the 2.0 release which will be contributed to Eclipse Luna. This will be addressed in the next service releases or latest until the Eclipse Luna release.
Documentation and Code Examples: The project documentation is hosted in Google Docs (see link below). Extenders should consult the documentation there for details. Code snippets showcasing how to use the low-level headless APIs are stored in the source projects and should provide sufficient information how to design your own recommenders on top of Eclipse Code Recommenders.
The Jayes bayesian network library part of the Code Recommenders project has been documented in an extensive blog post. See the project blog below for details.
Binary Model Format: For 2.0, the binary format of the recommendation model archives remained unchanged. The index format, however, changed and can be reviewed in the Google Docs covering the Models API. Please note that the binary model format is subject to change for 2.1 Release. We'll switch from plain Java object serialization to a custom binary format which will reduce model archive size by ~20% and improve model load time by another ~15%.
Recommenders 2.0 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.
Note that Recommenders 2.0 requires Eclipse Kepler (4.3) or later.
Users might experience small initial startup delays when triggering recommenders code completion the first time in Eclipse. Also, when loading a recommendation model from disk into the cache, developers may notice a small delay of less than a 100ms for the first time. Every subsequent access to the model and computation of recommendations is expected to consume no more than 20ms, taking 8ms in average.
Users of the subwords feature should be aware that using subwords on type completion may trigger long-running indexing operations in JDT and thus may occasionally fail due to timeout limits we put in place.
2.0 supports the same basic features as 1.0 but with noticeable changes in the UI. For instance, the “Recommenders proposals” content assist has been replaced by a more general and extensible “Intelligent Proposals” content assist, which is accessible to interested third-parties.
Subwords completion, previously available as a separate content assist, is now subsumed under the new “Intelligent Proposals” content assist.
Due to committer inactivity, the Snipmatch snippet completion engine, which was part of Code Recommenders 1.0, has been moved to Code Recommenders incubator. We are happy to say that we found a couple of interested GSoC students and mentors that are willing to continue the project. But for now, the project will stay in incubation state until ready for release.
Not applicable.
Code recommenders tracks actual bugs on Bugzilla, but uses Google docs to help committers track and prioritize the development of new features.
The project’s developer mailing list receives 30-80 mails per month, most of which serve coordination purposes amongst committers. A significant amount of traffic is due to new committers finding their way around the codebase.
Blog posts on topics surrounding Code Recommenders occur about bi-weekly and are syndicated on Planet Eclipse.
Code Recommenders maintains a Google Plus page and a Twitter account to keep in touch with its users. However, much of the communication happens over the project lead’s twitter and Google Plus account. A better support by the Eclipse Foundation (in particular on Google Plus) would be greatly appreciated.
The Eclipse Forum is mostly not used anymore.
The project uses Gerrit code review for all commits, both to the project itself and to its incubator projects. It uses its own HIPP instance for both the project itself and its incubator projects.
Eclipse Code Recommenders has recently attracted significant developer interest. In 2013, five Google Summer of Code on Eclipse Code Recommenders were completed successfully. The participating students have become committers in the Code Recommender incubator project, which now includes 5 separate subprojects.
A minor amount of coordination is required with the m2e Eclipse project, as both m2e and Eclipse Code Recommenders use runtime classes from the org.sonatype incarnation of the Aether library. Coordination is limited to spotting potential version conflicts in their use of that one library. Once the org.eclipse incarnation of Aether graduates from the Eclipse incubator, Eclipse Code Recommenders will switch to this implementation, thereby further reducing coordination effort with the m2e Eclipse project.
Links:
- Blog: http://www.codetrails.com/blog-tags/planeteclipse
- Bugzilla: https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Recommenders
- Git: http://git.eclipse.org/c/recommenders/org.eclipse.recommenders.git/
- Google Docs: https://drive.google.com/folderview?id=0B9Gf8BD0WA1SQk1DX0w1VmRIejg#list
- Google Plus: https://plus.google.com/b/113570884639387817308
- Twitter: https://twitter.com/recommenders