Quick Links

• Fishtail project page: http://www.cs.ubc.ca/labs/spl/projects/fishtail/
• Directory for the project page: /cs/web/cs.ubc.ca/docs/labs/spl/projects/fishtail
• Updated Java plugin source code: http://code.google.com/p/fishtail/
• Visual Studio plugin prototype source code: http://code.google.com/p/fishtail-vs/

Status (Jan 2011)

The plugin available from the project page is not compatible with the latest versions of Eclipse and Mylyn.

The plugin built from the updated source now runs against the latest versions of Mylyn (3.4.2) and Eclipse (3.6.1, Helios), but there remain a number of issues. Incompatibilities with the latest version of the Google search results page have been fixed. However, results are still not being displayed in the Fishtail view. The origin of this issue is still unknown.

The Visual Studio prototype is very minimal. It simply demonstrates the ability to periodically poll for the location of the cursor in the edit window, and map that location to a structural element in the program source.

Background

The Fishtail Eclipse plugin was originally developed by Nathan Hapke and Gail Murphy during Nathan's internship in late 2007. The function of the plugin is to automatically search the web for code samples and other pages applicable to the user's Mylyn task context. Search keywords are generated based on Java structure elements within the task context (e.g. class names, method names, package names). The user may augment the search input by manually entering additional keywords. Changes in the task context can automatically trigger searches, or they can be manually initiated by the user. Result links are listed in an Eclipse view.

In fall 2010, Gail and I (Nick) started exploring the possibility of building a similar plugin for Visual Studio 2010. I first wanted to familiarize myself with the existing plugin. It was no longer compatible with the latest versions of Mylyn and Eclipse, and the original source code repository had been lost. I decompiled the jarfile using JD (http://java.decompiler.free.fr/). I then fixed various compile errors, some resulting from the decompilation process, but most related to changes in the Mylyn API. The guide for porting from Mylyn 2.0 to 3.0 was very helpful in this process: http://wiki.eclipse.org/Mylyn/Porting_Guide/3.0.

I also needed to update the code to be compatible with the latest version of the Google search results page (unfortunately, the current implementation does not use the Google web search service, and is tightly coupled with the format of the Google search results page). While the plugin now loads successfully with the latest versions of Mylyn (3.4.2) and Eclipse (3.6.1, Helios), it is still not fully working, as search results do not show up in the Fishtail view.

While some time was expended trying to get the existing Eclipse plugin working, the majority of my work this past fall has been to explore the technical feasibility of building a similar plugin for Visual Studio 2010, and to understand better the value and novelty of the overall approach within the context of current research. Results of this work are summarized in the next two sections.

Fishtail Approach and Related Work

The Fishtail concept originates in work done by Reid Holmes, Robert Walker, and Gail on the Strathcona example recommendation tool (http://dx.doi.org/10.1145/1062455.1062491). In Strathcona, the programmer suggests a starting point for the search, either a class, method, or field declaration. The tool parses the surrounding source file, and extracts certain structural characteristics. It then queries a repository of examples for those that have matching structural characteristics. The matching heuristics are based on factors such as parent classes and interfaces, methods called, and types referenced.

Fishtail differs from Strathcona in a few key ways:

• Searches can be triggered automatically, without direct action on the part of the programmer, solely based on changes in the task context.
• Search is based on keywords derived from the task context, rather than structure matching. In the current implementation, the search keywords are extracted from the most recent change to the task context. The package name, class name, and method name associated with the change are used as keywords.
• The search is conducted across the entire web, using the Google search engine, rather than being confined to a custom repository of code examples.

Since the Strathcona work, other researchers have recognized the importance of examples in the development process, and sought ways to make relevant sample code more accessible to the programmer.

Codetrail (http://dx.doi.org/10.1109/VLHCC.2008.4639060) takes the approach of binding the Eclipse IDE and the Firefox browser through a communication channel. This channel allows the code under development to be linked with related pages on the web. Codetrail does not suggest new web pages to the programmer. Instead, it examines recently browsed web pages and uses keyword search and sequence alignment to identify pages that may be relevant to the user's source code.

Mica (http://dx.doi.org/10.1109/VLHCC.2006.32) is a web application which provides a programmer-centric frontend atop the Google search engine. Programmers enter their search keywords just as they would at the Google search page. Results that contain official Javadoc documentation and those that contain source code are flagged with special icons. Mica also scans a large range of the result pages for common programming keywords (e.g. class and method names from the JDK). The keywords are ranked by frequency and displayed in a separate column along with search results. Mica extends and customizes the web search process, but does not offer any integration with the IDE and the projects the developer is working on.

Like Mica, the Blueprint plugin for Adobe Flex Builder (http://dx.doi.org/10.1145/1753326.1753402) seeks to provide a programmer-centric search capability. Unlike Mica, however, Blueprint embeds the search capability within the development environment. The search box and results list are overlaid on top of the source code editor. Detailed information is displayed for each result, including a text summary as well as the example code.

The contributions of Mica and Blueprint largely relate to the way search results are presented to the programmer. Sourcerer (http://dx.doi.org/10.1007/s10618-008-0118-x), on the other hand, customizes the underlying search engine. Like Strathcona, it analyzes the structure of a body of existing code and builds a database that can support a variety of structure-based queries. For example, the user can query for definitions of classes whose name contains the term 'XMLParser', or examples where such a class is used. The different query types supported by Sourcerer correspond roughly to the different types of matching heuristics implemented in Strathcona. An important difference is that Sourcerer requires the user to explicitly enter the search keywords and type of query desired.

Unlike Strathcona and Fishtail, the above approaches do not use program structure as input to the search. A separate thread of research has continued to explore this strategy. A challenge with trying to use program structure is that the existing structure does not necessarily yield a good indication of the specific task the programmer now needs help with. Consequently, search results may be unfocused and broad. A number of research efforts provide more specific results by targeting a single, common development task: how to obtain an instance of a given output type, given a set of input types available at a given point in the code. Prospector (http://dx.doi.org/10.1145/1064978.1065018), XSnippet (http://dx.doi.org/10.1145/1167515.1167508) and PARSEweb (http://dx.doi.org/10.1145/1321631.1321663) are all examples of this basic approach.

Fishtail-VS: Visual Studio Prototype

I have done some technical exploration to see whether a plugin similar to Fishtail could be implemented in Visual Studio.

I have built a simple add-in for Visual Studio 2010 (source code available at the link above). This add-in uses the EnvDTE and EnvDTE80 namespaces (http://msdn.microsoft.com/en-us/library/1xt0ezx9.aspx) to interact with the development environment and program structure. The add-in periodically polls for the cursor location in the current document. It then uses the FileCodeModel2 interface (http://msdn.microsoft.com/en-us/library/envdte80.filecodemodel2.aspx) to retrieve the CodeElement2 instance corresponding to the cursor location. From CodeElement2, the add-in can identify the class and method where the cursor is located.

I have spent some time searching for a way to receive event notifications when the cursor position in the editor changes. The following forum post describes a hack to achieve this:

http://www.dotnetmonster.com/Uwe/Forum.aspx/vs-ext/600/Need-CodeElement-EditPoint-from-cursor-location-changed-event

It also looks like a text editor API newly added in Visual Studio 2010 may provide such events:

http://msdn.microsoft.com/en-us/library/microsoft.visualstudio.text.editor.itextcaret.positionchanged.aspx

Goals and Challenges for Fishtail-VS

The current set of search keywords generated by Fishtail seems insufficient. To get better results, we need to use similar heuristics to those employed in Strathcona. Thus, we need to start from the program elements in the task context, such as modified or selected methods and classes, and determine their parent classes and interfaces, the methods they invoke, and the types they reference. These are the elements that are more likely to generate search results relevant to what the programmer is trying to do. The problem then is how to select a subset of these elements to include as search keywords. Using just a single element may tend to give overly general results. By including a few elements, we may focus the result set on those that are of greater relevance to the task. But including too many elements as keywords is bound to result in an overly narrow result set.

It seems we may want to generate a few candidate queries, run them all, and then have an additional algorithm evaluate the results from each query, selecting those which are most promising. Results containing sample code can be compared to existing code within the project, using matching techniques similar to those employed by Strathcona.

In addition to code elements, the task context may link to a bug report. Another avenue to explore is whether results can be improved by including keywords from the bug report in the query.