# Remove Unused Fields
# Description
This rule finds the field declarations that are never used and removes them.
Reassignments in the same or in external Java files are not counted as active usages.
A configuration wizard allows users to choose whether to remove fields whose initializers may cause side effects (see Configuration).
Any annotation except for @Deprecated
and @SuppressWarnings
prevents the field declaration from being considered as unused.
# Avoiding Side Effects
In general, any method or constructor invocation may cause side effects that may be necessary for the correct behavior of the program execution.
Therefore, the initializers in field declarations or in the right-hand sides of field reassignments that may cause side effects are preventing the field from being removed by this rule.
Some exceptions are made for some popular Java builtin constructors and methods. For example:
- constructors of collections, maps, sets, and other popular Java classes, e.g.,
new ArrayList<>()
,new HashMap<>()
,new Object()
, etc... - methods for retrieving information about a collection without modifying it, e.g.,
contains()
,isEmpty()
,size()
,lastIndexOf()
, etc... - factory methods for collections, e.g.,
List.of()
,Set.of()
, etc...
# Benefits
Some benefits of removing unused code, and in particular unused fields, are:
- Reduces maintenance costs.
- Reduces the compilation time.
- May potentially eliminate unnecessary computations for unwanted side effects.
# Configuration
This rule, together with Remove Unused Methods and Remove Unused Types, provides a dedicated configuration wizard that allows users to:
- choose which fields to remove based on their access modifier. By default only the
private
modifier is selected. - choose the search scope for field references. It can either be set to
Project
orWorkspace
. - choose whether to deliberately remove the fields whose initializers may cause side effects. By default this option is not checked.
Users are advised to be cautions with this option as the side effects may be necessary for a correct behavior of the program execution.
The following is a shot of the configuration wizard:
When clicking Finish, jSparrow will search for unused fields (as described above), find and analyse their references, and compute the code changes. The changes are shown in a Dif-View and users can choose to accept the computed changes for each field:
# Tags
# Code Changes
Pre
public class UnusedFieldsSample {
public String publicUsedField = "";
public String publicUnusedReassignedField = "";
private String privateUsedField = "";
void foo() {
publicUnusedReassignedField = "";
BlackHole blackHole = new BlackHole();
blackHole.use(publicUsedField);
blackHole.use(privateUsedField);
}
}
Post
public class UnusedFieldsSample {
public String publicUsedField = "";
private String privateUsedField = "";
void foo() {
BlackHole blackHole = new BlackHole();
blackHole.use(publicUsedField);
blackHole.use(privateUsedField);
}
}
# Limitations
At most one field at a time can be removed from the field declarations with multiple declaration fragments.
Use a Java Refactoring Tool
No license required
You can review this refactoring on your code without a license by installing jSparrow to your Eclipse IDE. Install the plug-in from Eclipse IDE: Eclipse Marketplace.
System-wide Refactoring
Do you want to automate this refactoring (and many more) to your system-wide code? The automatic application of this system-wide refactoring can be unlocked by acquiring your jSparrow license.
# Properties
Property | Value |
---|---|
Rule ID | RemoveUnusedFields |
First seen in jSparrow version | 4.8.0 |
Minimum Java version | 1.1 |
Remediation cost | 2 min |