RefactoringMiner++: Enhanced Refactoring Detection

• RefactoringMiner++ is a family of refactoring-aware analysis systems that advance commit-level AST differencing and semantic mapping across Java and C++.
• It overcomes limitations of traditional diff tools by supporting multi-mappings, language-specific adaptations, and semantic constraints to reflect developers’ intent.
• Empirical benchmarks demonstrate high precision and recall in detecting refactorings, making it a valuable tool for accurate change analysis in complex commits.

RefactoringMiner++ is a name used in recent software-engineering literature for closely related systems built on RefactoringMiner. In one line of work, it denotes an enhanced, refactoring- and semantic-aware abstract syntax tree (AST) differencing tool that generates accurate, commit-level diffs intended to reflect the developer’s intent, especially in the presence of refactorings, inter-file moves, and one-to-many or many-to-one mappings (Alikhanifard et al., 2024). In another, it denotes an open-source refactoring detection tool that brings RefactoringMiner 3 from Java to C++ by replacing the Java-specific front-end with a Clang/libClang-based front-end that constructs a language-agnostic program model (Ritz et al., 24 Feb 2025). A later paper uses the same name in a prospective, design-oriented discussion of a hybrid detector informed by foundation models rather than as an already evaluated implementation (Simões et al., 15 Jul 2025). Across these usages, the unifying theme is refactoring-aware change analysis that attempts to separate behavior-preserving design changes from ordinary edits and behavior-altering modifications.

1. Scope, nomenclature, and problem setting

The literature uses the name “RefactoringMiner++” in at least three distinct but related senses. The following summary is useful because the term does not refer to a single invariant implementation across all papers.

Source	Use of the name	Main scope
(Alikhanifard et al., 2024)	Enhanced AST differencing tool built on RefactoringMiner	Java, commit-level AST diff
(Ritz et al., 24 Feb 2025)	Open-source refactoring detection tool for C++ based on RefactoringMiner 3	C++, refactoring detection and behavior-change reporting
(Simões et al., 15 Jul 2025)	Proposed next-generation design inspired by RefModel	Hybrid static plus foundation-model detection

The 2024 AST-differencing work starts from a specific critique of both line-based diffs and existing AST diff tools. Line-based diffs only capture additions and deletions at line granularity and ignore moves and updates, which obscures code review of complex changes and refactorings. Earlier AST diff tools improve on line diffs but are described as suffering from five core limitations: lack of multi-mapping support, matching semantically incompatible AST nodes, ignoring language clues, lack of refactoring awareness, and lack of commit-level diff support (Alikhanifard et al., 2024). RefactoringMiner++ is introduced there as a system that resolves all five.

The 2025 C++ work frames the problem differently. It emphasizes that refactorings are frequent, behavior-preserving changes that often co-occur with behavior-altering modifications in tangled commits, complicating code review, integration, and mining commit histories. In that context, the notable gap is language support: the field has strong Java support, but there is no publicly available refactoring detection tool for C++ projects. RefactoringMiner++ is presented as filling that gap while remaining open-source (Ritz et al., 24 Feb 2025).

A later foundation-model paper broadens the problem setting further by arguing that rule-based and static-analysis-based detectors are difficult to extend and maintain, especially across languages and subtle hierarchy-sensitive operations. That paper evaluates RefModel rather than RefactoringMiner++, but it proposes a possible future “RefactoringMiner++” architecture that combines static candidate generation with large-model validation and direct diff-based classification (Simões et al., 15 Jul 2025). This suggests that the name has become associated not only with one implementation, but with a broader research agenda around refactoring-aware differencing and detection.

2. Core Java AST-differencing model

In the 2024 formulation, RefactoringMiner++ is an enhanced AST differencing tool that builds on top of RefactoringMiner to generate accurate, commit-level diffs across files and modules. Its central claim is that AST differencing should be semantic-aware, language-aware, and refactoring-aware rather than purely structural (Alikhanifard et al., 2024).

The architecture retains RefactoringMiner’s four-phase matching workflow. Phase 1 is top-down matching of type, method, and field declarations with identical signatures across versions. Phase 2 is bottom-up matching for unmatched declarations, where statement mappings are computed for every pair of unmatched methods and then sorted to select best matches, enabling detection of method renames, parameter additions and removals, return-type and parameter-type changes, and splits and merges. Phase 3 addresses class-level refactorings by computing intersections of method and field signatures to detect class renames, moves, package moves, and splits and merges; for matched type pairs, Phases 1 and 2 are re-run. Phase 4 considers remaining unmatched methods and fields and computes pairwise statement mappings to detect inter-file moves, including pull up, push down, and extract class or superclass (Alikhanifard et al., 2024).

AST diff generation is layered on top of this workflow. The generator first creates initial mappings $M$ from matched declarations and their statement mappings. It then adds mappings $A$ derived from refactoring instances, including declaration mappings, multi-mappings, intra-file and inter-file move mappings, and sub-expression mappings based on refactoring mechanics. Conflicts are resolved by prioritizing refactoring-derived mappings: if a mapping in $A$ conflicts with one in $M$, the conflicting mapping from $M$ is removed and the refactoring-derived mapping is added; otherwise, the mapping from $A$ is added alongside (Alikhanifard et al., 2024). This priority rule is the mechanism by which the overall diff becomes explicitly refactoring-aware.

The tool’s semantic-aware matching also modifies GumTree 3.0 Simple for fine-grained subtree comparison. For sub-expression matching, the matcher runs with minHeight reduced to 1, improving recall on shallow structures. A semantic constraint is added in the top-down phase to prevent matching SimpleName nodes whose parents have different AST types, such as a type name with a variable name or a method name with a variable name. The system also repairs mismatched leaf matches involving SimpleName and Operator by removing mismatches at the parent level and adding the correct parent mapping when necessary, with the stated goal of producing cleaner, more granular edit actions (Alikhanifard et al., 2024).

3. Matching principles, multi-mappings, and refactoring mechanics

The most distinctive feature of RefactoringMiner++ in the 2024 paper is support for one-to-many and many-to-one mappings. Existing tools are described as constraining each AST node to belong to only one mapping, which prevents faithful representation of duplication elimination and duplication introduction. RefactoringMiner++ instead preserves multi-mappings when they are justified by conditional-branch structure or refactoring mechanics, such as an enhanced-for variable mapped to multiple lambda parameters or multiple duplicated fragments matched to a single extracted body (Alikhanifard et al., 2024).

Candidate ranking is based on explicit similarity measures and context-sensitive tie-breakers. For a mapping $M = (m_1, m_2)$, the paper defines edit-distance(M) as the Levenshtein distance between statements, depth(m) as the number of composite parents until the method body, parent-edit-distance(M)[i] as the Levenshtein distance between the $i$th parents of $m_1$ and $m_2$, direct-parent-edit-distance(M) as parent-edit-distance(M)[1], parent-edit-distance-sum(M) as the sum of parent edit distances, depth-diff(M) as the absolute depth difference, and index-diff(M) as the absolute difference between statement indices. For composite mappings, child-match-ratio(M) is the number of matched child pairs divided by $A$0, and identical-composite-children(M) counts matched composite child pairs with zero edit distance (Alikhanifard et al., 2024).

Leaf mapping ranking favors multi-mappings; mappings that become identical after undoing overlapping extract or inline variable refactorings; identical neighbors before and after; same nesting and first non-block parent type; smaller parent-edit-distance-sum; smaller edit distance; and, under edit-distance ties, smaller parent-edit-distance-sum, depth-diff, index-diff, and direct-parent-edit-distance. Composite mapping ranking favors twice larger child-match-ratio, mappings that become identical after undoing overlapping extract or inline variable refactorings, lower edit distance, more identical composite children, higher child-match-ratio, and smaller depth-diff and index-diff (Alikhanifard et al., 2024). The ranking rules are therefore explicitly designed to privilege semantic plausibility and statement continuity over raw structural similarity alone.

Call-site scoping is another key mechanism. For Extract Method and Inline Method, the tool uses the number and locations of call sites to restrict scope and to repeat matching per region. When multiple calls to the extracted method exist, the mapping process is executed as many times as there are calls, each time limiting unmatched left-side statements to the parent block encompassing the specific call. When duplicated fragments lie in the method-body scope, contiguous regions of identical mappings are identified and previously matched regions are excluded in subsequent runs (Alikhanifard et al., 2024). This design is specifically intended to preserve multi-mappings without conflation.

Refactoring mechanics also drive sub-expression mappings. The paper lists several examples: in Extract Method, arguments on the right are mapped to corresponding sub-expressions on the left; Inline Method reverses this; Extract or Inline Variable and Field map initializer expressions to original or replaced sub-expressions; Replace Loop with Pipeline and Replace Pipeline with Loop align loop iteration collections, conditional bodies, and action statements with stream or lambda chains; Split or Merge Conditionals align sub-expressions split or merged under && and ||; and Merge Catch produces many-to-one mappings for similar catch bodies and sub-expression mappings for exception types moved to union types (Alikhanifard et al., 2024). This is a strong indication that the system treats refactorings as first-class semantic events rather than as incidental outcomes of generic tree matching.

4. Benchmark, evaluation protocol, and empirical results

The 2024 paper introduces what it describes as the first benchmark of AST node mappings, intended both to evaluate RefactoringMiner++ and to compare it with state-of-the-art tools. The benchmark includes 800 bug-fixing commits from Defects4J and 188 refactoring commits from the Refactoring Oracle; the refactoring dataset derives from 546 commits originally and includes over 11K refactorings and code changes historically, but was filtered to commits with 1–2 modified files for tractability (Alikhanifard et al., 2024).

Ground truth is stored as human-readable JSON per modified file with intra-file and inter-file mappings. Each mapping records left and right code and AST type and location information. Metadata per commit includes whether multi-mappings are present, left and right churn, challenge level, and comments. Ground truth construction combined tool outputs, manual inspection based on criteria such as statement continuity, developer intent, aesthetic clarity, behavior-preserving control-flow restructuring, consistent renaming, and inline comment locations, with adjudication for around 3% debatable cases (Alikhanifard et al., 2024).

Accuracy is measured with precision, recall, and F-score, with $A$1, $A$2, and $A$3. The paper gives $A$4, $A$5, and $A$6 (Alikhanifard et al., 2024).

The reported results are unusually strong on refactoring-heavy changes. For multi-mapping accuracy, RefactoringMiner++ achieved 99.7% precision and 98.4% recall, whereas GumTree 3.0 simple had 59.3% precision and 10.3% recall, GumTree 3.0 greedy 47.0% and 10.4%, GumTree 2.1.0 44.3% and 8.7%, MTDiff 29.6% and 7.5%, and IJM 18.3% and 2.6%. For semantically incompatible mappings, RefactoringMiner++ generated 0 semantic violations across six sensitive AST node types, while other tools produced many violations. For program element mappings, it reported 99.9% precision and 96.4% recall across all program elements with changed ASTs; types and enums were matched with 100% precision and recall, and fields with 98.8% precision and 98.5% recall (Alikhanifard et al., 2024).

The paper also reports 99.6% precision and 99.4% recall on statement-level mappings in refactoring-affected subtrees, 99.6% precision and near-perfect recall for inter-file mappings, and 99.8% precision with 99.5% recall overall on the Refactoring dataset at statement level. At fine-grained sub-expression level, RefactoringMiner++ held 99.7% precision and 99.3% recall. The perfect-diff rate was 87.9% overall at statement level and 82.5% overall when sub-expressions were included. Runtime was slower than GumTree 3.0 simple—2.5x slower on median and 3.3x slower on average in Defects4J, and 4.8x and 6.8x slower in the Refactoring dataset—but remained within the same order of magnitude and under 800 ms per bug-fixing commit on median, which the authors argue is practical for CI and code review workflows (Alikhanifard et al., 2024).

The same evaluation also isolates the effect of improvements over RefactoringMiner 2.0. Statement-level recall improved by 10–13% and precision by 0.6–3.4%, especially in refactoring-heavy commits, attributed to improved tie-breaking, processing of previously unhandled AST parts, new refactoring types contributing mappings, and broader replacement support. Method declaration recall improved by 2–6%, notably in anonymous classes (Alikhanifard et al., 2024). Within the scope of the benchmark, these results position RefactoringMiner++ as a tool whose empirical advantage is concentrated precisely where conventional AST differencers are weakest: refactorings, inter-file movement, and semantically constrained alignment.

5. C++ adaptation and refactoring detection

The 2025 C++ paper repurposes the RefactoringMiner++ name for a different but related contribution: an open-source refactoring detection tool that brings RefactoringMiner 3 to C++. The key design choice is to keep RefactoringMiner’s detection core while replacing the Java front-end with a C++ front-end that traverses Clang/libClang ASTs, constructs a language-agnostic program model, serializes that model to human-readable JSON, and feeds it to a modified RefactoringMiner (Ritz et al., 24 Feb 2025).

Several C++-specific modeling adaptations are required. Namespaces are mapped to packages because RefactoringMiner expects packages. Since C++ allows free functions and variables at namespace or global scope, the tool introduces artificial classes per namespace to wrap such top-level entities so that they fit RefactoringMiner’s model and can participate in method-level and field-level detections. Structs are treated as classes, accounting for default access differences. Multiple inheritance is represented by recording all parent-child relations in a UMLGeneralization list, because RefactoringMiner’s class representation allows up to one base class. Templates are represented as generics in the model, providing basic support for templated code, and source tokens are parsed where libClang does not expose sufficient AST details, such as for decltype and noexcept (Ritz et al., 24 Feb 2025).

The tool can detect many refactoring types that carry over naturally from Java to C++. The paper’s seeded dataset shows equivalent Java and C++ detection for Move Class, Extract Method, Change Variable Type, Change Parameter Type, Rename Parameter, Change Return Type, Rename Method, Pull Up Method, Move Method, Rename Variable, Move Field, Change Field Type, Extract and Move Method, Rename Field, Pull Up Field, and Inline Method. The demonstration example also shows Rename Class, Add Attribute Modifier, Rename Method, Add Method Modifier, and Rename Parameter. Beyond refactorings, the tool reports behavior-altering code modifications, which is explicitly motivated as a way to help reviewers untangle mixed commits (Ritz et al., 24 Feb 2025).

The illustrative example in the paper changes Circle to CircleCalculator, adds inline static const to PI, renames getArea to calcArea, adds static modifiers, renames a parameter, introduces a new method calcSectorArea, and fixes a bug in circumference computation. RefactoringMiner++ detected the refactorings on the relevant lines and also reported behavior-altering changes—an added method and a modified statement—without misclassifying them as refactorings. On the seeded evaluation dataset, both RefactoringMiner 3 for Java and RefactoringMiner++ for C++ “successfully located all seeded refactorings and, thus, produced equivalent results”; the paper therefore states the implication that $A$7 and $A$8 for the tested cases, yielding precision, recall, and $A$9 on that dataset (Ritz et al., 24 Feb 2025).

The paper is careful about limitations. The initial version compares two revisions of a single C++ file, so multi-file projects with .h, .hpp, and .cpp splits are not yet fully supported. Lambdas, local classes, and nested classes are not currently supported. The paper also does not discuss macros and preprocessor directives, operator overloading, overload resolution, default arguments, move semantics, constexpr, or linkage nuances, identifying them implicitly as areas for future modeling and validation (Ritz et al., 24 Feb 2025). Accordingly, the C++ contribution is best understood as a front-end and modeling extension of the RefactoringMiner paradigm rather than as a fully benchmarked, project-scale successor to the Java AST-differencing work.

6. Relation to foundation-model approaches and prospective directions

The 2025 RefModel paper does not present a released RefactoringMiner++ system, but it is directly relevant because it proposes a future design under that name and frames a possible next step in refactoring detection research. RefModel itself detects refactorings using foundation models and one-sentence refactoring definitions, with prompts that present either full before/after code for small programs or GitHub diffs for real commits. It evaluates Phi4-14B, Claude 3.5 Sonnet, Gemini 2.5 Pro, and o4-mini-high against RefactoringMiner, RefDiff, and ReExtractor+ (Simões et al., 15 Jul 2025).

In real-world settings, the paper reports recall of 93.8% for Gemini 2.5 Pro and o4-mini-high, 92.2% for Claude 3.5 Sonnet, and 88.6% for RefactoringMiner, while precision was 82.2%, 81.1%, 77.6%, and 41.9%, respectively. Claude 3.5 Sonnet and Gemini 2.5 Pro jointly identified 97% of all refactorings in the real-world dataset, and the paper also reports encouraging cross-language generalization to Python and Golang (Simões et al., 15 Jul 2025). These are findings about RefModel, not about RefactoringMiner++, and that distinction matters.

What the paper then proposes for a prospective “RefactoringMiner++” is a hybrid ensemble with static-first candidate generation, an LLM-first pass on the diff, LLM confirmation or correction of static candidates, and decision fusion via $A$0, with thresholds $A$1 chosen by validation. The paper also sketches JSON-oriented prompts, selective prompting for difficult cases such as Inline Method and Pull Up versus Push Down, and caching and batching strategies for cost control (Simões et al., 15 Jul 2025). Since these details are presented as design guidance rather than as evaluated implementation results, they should be read as a roadmap rather than as established properties of an existing tool.

Taken together with the earlier papers, the future directions around RefactoringMiner++ are comparatively clear. The Java AST-differencing work points toward intelligent code-review assistance, navigation strategies, explanation assistance using commit messages and issue discussions, and multi-language extension (Alikhanifard et al., 2024). The C++ work identifies multi-file support, lambdas, local and nested classes, and more comprehensive real-world validation as immediate engineering priorities (Ritz et al., 24 Feb 2025). The RefModel paper suggests that some future variants may combine refactoring-aware static analysis with model-based natural-language classification and explanation (Simões et al., 15 Jul 2025). A plausible implication is that “RefactoringMiner++” has evolved from the name of a single AST-differencing enhancement into a broader family of refactoring-aware analysis systems centered on precise semantic matching, commit-level reasoning, and increasingly language-agnostic or hybrid detection strategies.