defects4j icon indicating copy to clipboard operation
defects4j copied to clipboard

faulty-related import statements that are considered faults of omission

Open jose opened this issue 1 year ago • 1 comments

Hi @rjust and @Greg4cr,

While performing the analyzis described in #500 I found two bug-introducing patches that could further improved, regarding the changes each patch makes to some import statements.

  1. The current bug-introducing patch for Cli-7 adds an import statement to the buggy version and removes another import statement:
+import java.util.HashSet;
 import java.util.Iterator;
-import java.util.LinkedHashSet;
 import java.util.Set;

as both changes occur in non-consecutive lines of code, in the buggy version, the import java.util.HashSet; statement is considered part of the buggy behavior and the removed import java.util.LinkedHashSet; statement is considered a fault of omission.

  1. Similar, the current bug-introducing patch for Cli-36 (OptionGroup.java file) adds an import statement to the buggy version and removes another import statement:
+import java.util.HashMap;
 import java.util.Iterator;
-import java.util.LinkedHashMap;
 import java.util.Map;

as both changes occur in non-consecutive lines of code, in the buggy version, the import java.util.HashMap; statement is considered part of the buggy behavior and the removed import java.util.LinkedHashMap; statement is considered a fault of omission.

I would suggest we re-order those import statements in the bug-introducing patches as

 import java.util.Iterator;
+import java.util.HashSet;
-import java.util.LinkedHashSet;
 import java.util.Set;

and

 import java.util.Iterator;
+import java.util.HashMap;
-import java.util.LinkedHashMap;
 import java.util.Map;

so that those import statements are only considered buggy-related and not faults of omission (which they are not).

Extra: related to this, the current bug-introducing patch for Cli-1 could also be further improved.

The patch-minimization guide states that code refactoring should be removed from bug-introducing patches

Since refactoring does not affect the behavior of the code, it is not considered part of a bug fix, and the changes introduced during refactoring should be removed from the Defects4J patch.

I wonder whether introducing a custom refactoring of import statements would somehow incentive others to perform other kind of refactors in the bug-introducing patches provided by Defects4j. Please, let me know what you think about it.

jose avatar Mar 10 '23 13:03 jose

Ah, interesting. I support making this change, as it more accurately reflects the actual bug (and its fix).

I wonder whether introducing a custom refactoring of import statements would somehow incentive others to perform other kind of refactors in the bug-introducing patches provided by Defects4j. Please, let me know what you think about it.

Patch minimization requires some degree of interpretation. I am certain we have made other similar "refactorings" when performing minimization. I am not bothered by a limited amount of refactoring to isolate the bug. I think the key is to emphasize that such refactoring:

  • Should only be in service of isolating and minimizing the bug.
  • Should be limited to smallest amount of change required to separate the bug from unrelated code changes.

Greg4cr avatar Mar 14 '23 09:03 Greg4cr