A profile enables you to define or connect to a set of SemDiff repositories. A profile is associated with a database (either local or remote) to store the analysis data computed from the repositories. There are two types of profiles:
- Local profiles enable you to create and manage your own repositories. Choose this profile type if you wish to perform your own analysis.
- Remote DB profiles enable you to access repositories stored on a remote DB. All computations are performed on the client and you cannot modify the data, but you can perform your own analysis and store the results locally.
A SemDiff repository is associated with a source repository (CVS and Subversion are currently supported) and stores all transactions and analysis data. For example, you can have a repository that is associated with the Eclipse CVS server and with the org.eclipse.ui and org.eclipse.jdt.core modules. By default, the SemDiff repository will contain all transactions (change sets) committed in these modules, the files that were changed, the Java elements that were changed, the method calls, and the field accesses that were added and removed in each transaction.
A transaction in SemDiff represents a unit of work in the evolution of a program. It is also called change set in the literature. A transaction contains all files that were committed (added, removed, or modified) together. Because not all version control systems explicitly keep track of files that were committed together (e.g., CVS), SemDiff uses a common strategy to infer the transactions from such systems. A transaction is also the main unit of work for SemDiff: analyses are performed on each transaction and the results are associated with each transaction.
A detector in SemDiff is responsible for performing one analysis on transactions. By default, SemDiff ships with three detectors:
- StructDiff performs syntactic analysis on each file in a transaction and determines which Java elements were changed (e.g., method abc() was modified in file App.java between versions 1.1 and 1.2).
- CallDiff determines which calls were added or removed (e.g., a call to method xyz() was added in version 1.2 of method abc() in file App.java).
- FieldDiff determines which fields accesses were added or removed (e.g., a read access to field System.out was removed in version 1.2 of method abc() in file App.java).
A detector can depend on an arbitrary number of detectors (cycles are detected and forbidden). For example, CallDiff depends on StructDiff. It is possible to define your own detectors through the detector extension point.
SemDiff was originally created to recommend adaptive changes when a client program broke because of the evolution of a framework or library. If a call to a framework no longer works (e.g., the method no longer exists) and you captured the framework's history in a SemDiff repository, you can ask SemDiff to recommend you equivalent method calls. For example, if you were calling method m1(), which no longer exists, SemDiff might recommend you to call method m1_2() as a replacement.
To get a recommendation for a framework, activate the SemDiff repository containing the framework's history (i.e., with the results of StructDiff and CallDiff), select a broken method call in the Java Editor, right-click to open the context menu and select SemDiff -> Get Call Recommendations.
Partial Program Analysis
Because SemDiff only retrieves files that were changed together in a transaction, it does not have access to the whole program when performing its analyses. Certain detector, like CallDiff, must perform basic static analysis (e.g., determine the methods that are called), which is usually not possible if the whole program is not available. SemDiff thus relies on a technique, Partial Program Analysis (PPA), to enable static analysis for partial Java programs. Because PPA must be installed for SemDiff to work, you will encounter various options (e.g., menu items) related to PPA. Information about these options are available on the PPA for Eclipse website.