Duplicates Finder (Java)
The Duplicates Finder (Java) build runner is intended for catching similar code fragments and providing a report on discovered repetitive blocks of Java code. This runner is based on IntelliJ IDEA capabilities, so an IntelliJ IDEA project file (.ipr) or directory (.idea) is required to configure the runner.
The Duplicates Finder (Java) runner can also find Java duplicates in projects built by Maven2 or above.
This page contains reference information about the following Duplicates Finder (Java) build runner's fields.
IntelliJ IDEA Project Settings
Option | Description |
|---|---|
Project file type | To be able to run IntelliJ IDEA inspections on your code, TeamCity requires either an IntelliJ IDEA project file/directory, Maven |
Path to the project | Depending on the type of project selected in the Project file type, specify here:
This information is required by this build runner to understand the structure of the project. |
Detect global libraries and module-based JDK in the | This option is available if you use an IntelliJ IDEA project. In IntelliJ IDEA, the module settings are stored in |
Check/Reparse Project | This option is available if you use an IntelliJ IDEA project. Click this button to reparse your IntelliJ IDEA project and import the build settings right from the project, for example the list of JDKs. |
Working directory | Enter a path to the Build Working Directory if it differs from the Build Checkout Directory. Optional, specify if differs from the checkout directory. |
Unresolved Project Modules and Path Variables
This section is displayed, when an IntelliJ IDEA module file (.iml) referenced from an IPR-file:
cannot be found;
allows you to enter the values of path variables used in the IPR-file.
To refresh values in this section, click Check/Reparse Project.
Option | Description |
|---|---|
<path_variable_name> | This field appears if the project file contains path macros, defined in the Path Variables dialog of the IntelliJ IDEA settings. In Set value to field, specify a path to the project resources to be used on different build agents. |
Project JDKs
This section provides the list of JDKs detected in the project.
Option | Description |
|---|---|
JDK Home | Use this field to specify the JDK home for the project. |
JDK Jar File Patterns | Click this link to open a text area where you can define templates for the jar files of the project JDK. Use Ant rules to define the jar file patterns. The default value is used for Linux and Windows operating systems: jre/lib/*.jar
For macOS, use the following lines: lib/*.jar
../Classes/*.jar
|
IDEA Home | If your project uses the IDEA JDK, specify the location of the IDEA home directory |
IDEA Jar Files Patterns | Click this link to open a text area, where you can define templates for the jar files of the IDEA JDK. |
Option | Description |
|---|---|
JDK | Select a JDK. This section details the available options. The default is |
JDK home path | The option is available when <Custom> is selected above. Use this field to specify the path to your custom JDK used to run the build. If the field is left blank, the path to JDK Home is read either from the |
JVM command line parameters | Additional JVM command line parameters allow you to set initial and maximum heap sizes, enable additional logging, select the required bytecode verifier mode, and more. You can specify both standard (begin with To specify multiple command line parameters, use space as a separator. For example: -verbose:gc -Xdiag -Xcomp -Xmx512m -Xms256m |
Java Parameters
Duplicate Finder Settings
Option | Description |
|---|---|
Test sources | If this option is checked, the test sources will be included in the duplicates analysis. |
Include / exclude pattern | Optional, specify to restrict the sources scope to run duplicates analysis on. For details, refer to the section below. |
Detalization level | Use these options to define which elements of the source code should be distinguished when searching for repetitive code fragments. Code fragments can be considered duplicated if they are structurally similar, but contain different variables, fields, methods, types or literals. Refer to the samples below: |
Distinguish variables | If this option is checked, the similar contents with different variable names will be recognized as different. If this option is not checked, such contents will be recognized as duplicated: public static void main(String[] args) {
int i = 0;
int j = 0;
if (i == j) {
System.out.println("sum of " + i + " and " + j + " = " + i + j);
}
long k = 0;
long n = 0;
if (k == n) {
System.out.println("sum of " + k + " and " + n + " = " + k + n);
}
}
|
Distinguish fields | If this option is checked, the similar contents with different field names will be recognized as different. If this option is not checked, such contents will be recognized as duplicated: myTable.addSelectionListener(new SelectionListener() {
public void widgetDefaultSelected(SelectionEvent e) {
}
/*.....**/
});
myTree.addSelectionListener(new SelectionListener() {
public void widgetDefaultSelected(SelectionEvent e) {
}
/*.....**/
});
|
Distinguish methods | If this option is checked, the methods of similar structure will be recognized as different. If this option is not checked, such methods will be recognized as duplicated. In this case, they can be extracted and reused. Initial version: public void buildCanceled(Build build, SessionData data) {
/* ... **/
for (IListener listener : getListeners()) {
listener.buildCanceled(build, data);
}
}
public void buildFinished(Build build, SessionData data) {
/* ... **/
for (IListener listener : getListeners()) {
listener.buildFinished(build, data);
}
}
After analyzing code for duplicates without distinguishing methods, the duplicated fragments can be extracted: public void buildCanceled(final Build build, final SessionData data) {
enumerateListeners(new Processor() {
public void process(final IListener listener) {
listener.buildCanceled(build, data);
}
});
}
public void buildFinished(final Build build, final SessionData data) {
enumerateListeners(new Processor() {
public void process(final IListener listener) {
listener.buildFinished(build, data);
}
});
}
private void enumerateListeners(Processor processor) {/* ... **/
for (IListener listener : getListeners()) {
processor.process(listener);
}
}
private interface Processor {
void process(IListener listener);
}
|
Distinguish types | If this option is checked, the similar code fragments with different type names will be recognized as different. If this option is not checked, such code fragments will be recognized as duplicates. new MyIDE().updateStatus()
new TheirIDE().updateStatus()
|
Distinguish literals | If this option is checked, similar line of code with different literals will be considered different. If this option is not checked, such lines will be recognized as duplicates. myWatchedLabel.setToolTipText("Not Logged In");
myWatchedLabel.setToolTipText("Logging In...");
|
Ignore duplicates with complexity lower than | Complexity of the source code is defined by the amount of statements, expressions, declarations and method calls. Complexity of each of them is defined by its cost. Summarized costs of all these elements of the source code fragment yields the total complexity. Use this field to specify the lowest level of complexity of the source code to be taken into consideration when detecting duplicates. For meaningful results start with value 10. |
Ignore duplicate subexpressions with complexity lower than | Use this field to specify the lowest level of complexity of subexpressions to be taken into consideration when detecting duplicates. |
Check if Subexpression Can be Extracted | If this option is checked, the duplicated subexpressions can be extracted. |
Include / exclude patterns are newline-delimited set of rules of the form:
Where the pattern must satisfy these rules:
must end with either
**or*(this effectively limits the patterns to only the directories level, they do not support file-level patterns)references to modules can be included as
[module_name]/<path_within_module>Some notes on patterns processing:excludes have precedence over includes
if include patterns are specified, only directories matching these patterns will be included, all other directories will be excluded
"include" pattern has a special behavior (due to underlying limitations): it includes the directory specified and all the files residing directly in the directories above the one specified.
Example: