Hybrid Learning-guided Metaheuristic for Refactoring selection

Refactoring Selection under AST Conflicts This repository is a research replication package for a benchmark of search-based refactoring selection. It studies how to choose refactorings from historical software changes when candidate transformations can conflict in the abstract syntax tree (AST), while optimizing code-quality outcomes under a selection budget. The central experiment combines empirically mined refactoring impacts, learned surrogate models, AST-derived conflict graphs, exact and heuristic optimizers, and a physical Java compilation validation. The executable experiment is contained in paper1.ipynb; the CSV files in results/ are the preserved result artifacts from a prior run. Reproducibility status: this package contains the notebook and previously generated data/results, but it does not currently provide a pinned dependency lockfile or a consistently configured one-command rerun. The notebook has conflicting platform/path assumptions (described below). The saved results and provenance should therefore be treated as the preserved experiment outputs, not as evidence that an unmodified fresh checkout will regenerate every table byte-for-byte. What the experiment does The study is organized as nine sequential notebook steps: Provision tools and Python packages. The first cell checks the local environment and installs/checks dependencies, including RefactoringMiner 3.0.7 and Apache Maven 3.9.11. Prepare source repositories and chronological splits. It uses five repositories—Joda-Time, Spring Framework, NumPy, Elasticsearch, and LLVM—and divides mined commits chronologically into train, validation, and test partitions at 70%, 15%, and 15%. Mine refactoring effects and benchmark surrogate models. It mines historical refactorings and code-quality metric changes, produces Table 2, constructs sequential historical data, and evaluates 11 surrogate model architectures for Table 3. Build candidate instances and AST conflict graphs. It derives candidate pools and conflicts from the repository data, serializes optimization instances, and produces the dataset/topology summary (Table 4). Run Study A. It benchmarks 25 algorithmic rows, including CP-SAT references, greedy methods, and stochastic/metaheuristic methods. It produces the main benchmark, solver-gap, effect-size, and per-repository results (Tables 5, 6, 10, and 13), plus individual run records. Run ablations and operator attribution. It evaluates a 16-configuration ablation matrix and a two-order Shapley attribution (Tables 7 and 8). Run Study B and weight sensitivity. It evaluates temporal/non-linear optimization at budgets B = 50, 150, and 300 and tests five objective weight profiles (Tables 9 and 12). Validate physical Java transformations. It samples 30 production Java classes from Joda-Time and Spring Framework, applies strategies, invokes Java compilation, and summarizes build success and code metrics (Table 11). Assemble and audit outputs. It checks experimental data, writes checksums, and packages result CSVs for export. The experimental inputs cover both behavior and structural feasibility: Historical commit data and mined refactoring/metric impacts. A sequence dataset and pretrained surrogate weights. Per-repository optimization instance JSON files and conflict-graph metadata. Source snapshots and commit history for the five target repositories. Physical Java build logs and class-level validation data. Repository contents Path Purpose paper1.ipynb All nine executable experiment steps; there is no separate Python application or CLI. content/repos/ Repository source snapshots and Git metadata used for mining/validation. content/mined_data/ Mined inputs, sequence data, surrogate weights, split metadata, and the Table 4 topology summary. instances/ Five serialized repository optimization instances: Elasticsearch, Joda-Time, LLVM, NumPy, and Spring Framework. mined_data/ A second copy of selected mined inputs and summary tables. results/ Preserved benchmark summaries, run-level records, physical-validation logs, provenance, and a SHA-256 manifest. tools/ Bundled Maven and RefactoringMiner launchers/distributions. physical_builds/ Workspace directory used by the physical-build workflow; it is empty in this checkout. EXP.zip Compressed data bundle. Its contents are primarily under content/; it is not the same as the result tables in results/. Some data is duplicated across content/mined_data/, mined_data/, instances/, and results/. Keep these paths intact when running the notebook: different steps use different directory resolvers and output locations. Preserved results The main result files are: File Contents results/table2_refactoring_impacts.csv Summary of mined impact estimates by refactoring type. results/table3_surrogate_baselines.csv Historical and synthetic surrogate-model baseline metrics. content/mined_data/table4_datasets_topology.csv Repository candidate-pool and conflict-graph topology summary. results/table5_main_benchmark.csv Study A aggregate benchmark results. results/table6_solver_gaps.csv CP-SAT bounds, incumbents, and solver gaps. results/table7_ablation_study.csv The 16-configuration ablation study. results/table8_shapley_attribution.csv Operator attribution results. results/table9_study_b.csv Study B aggregate results by budget. results/table10_cliffs_delta.csv Per-repository Cliff's delta comparisons. results/table11_physical_validation.csv Physical Java compilation and metric validation summary. results/table12_weight_sensitivity.csv Objective-weight sensitivity results. results/table13_per_repository_stats.csv Per-repository scores for the evaluated algorithms. results/study_a_run_level_dataset.csv Individual Study A runs, including seed, score, and timing/metric fields. results/study_b_run_records.csv Individual Study B runs. results/physical_deployment_logs.csv Class/strategy-level compilation and metric logs. results/mined_refactorings.csv Mined refactoring records. results/chronological_splits.json Commit-level chronological split and snapshot metadata. results/README_PROVENANCE.txt Recorded runtime provenance and a description of the result artifacts. results/checksums.sha256 SHA-256 checksums for four listed result/data files. The provenance file records a Google Colab Linux environment with Ubuntu 22.04, Python 3.11.0, and CPU-only PyTorch 2.14.1. The notebook metadata also names Python 3.11.0. This environment record is useful context, but it does not resolve the portability mismatch in the current notebook. Requirements The notebook's Windows provisioning cell lists these Python packages: torch, torchvision ortools lizard, radon, javalang gitpython xgboost scikit-learn, scipy, pandas, numpy, statsmodels, openpyxl The workflow also uses Git, Java/JDK, Apache Maven 3.9.11, and RefactoringMiner 3.0.7. The notebook attempts to provision/check several dependencies, but Python package versions are not pinned in a requirements file or lockfile. Consequently, installing the same package names later is not sufficient to guarantee identical solver behavior, model results, or timings. Running the notebook Obtain the complete repository, including content/, instances/, mined_data/, results/, and tools/. Do not launch the notebook from a different working directory; the experiment uses paths relative to its working root as well as an absolute /content path. Use a Python 3.11 kernel in VS Code with the Jupyter extension, or another Jupyter environment that can run the notebook. Ensure Git and a Java/JDK installation are available. The first notebook cell is configured to run only on Windows and attempts to provision/check tools and packages. Review its downloads and installation commands before running it; it may require network access and system-level installation permissions. Run all notebook cells in order, from Step 1 through Step 9. Later steps depend on variables, data, and files created by earlier steps. Do not run individual later cells in a fresh kernel unless the relevant intermediate data and state have already been prepared. Review the Step 9 audit output and compare regenerated artifacts with the preserved results/ files. Runtime, random seeds, package/solver versions, and native compilation environments can affect regenerated values. Important platform/path limitation The current notebook is not yet a portable, clean-checkout reproduction workflow: Step 1 raises an error unless it is running on Windows. Step 2 sets CONTENT_ROOT to the absolute path /content, a convention used by Colab/Linux. On Windows this resolves at the root of the current drive, not to this checkout's content/ directory. The result provenance describes a Colab/Linux run, which conflicts with the Windows-only guard in the current Step 1 cell. Before attempting a full rerun, reconcile the path and platform assumptions in the notebook and verify where each step reads/writes data. For a Windows checkout, Step 2's CONTENT_ROOT would need to point to this checkout's content/ directory (for example, Path.cwd() / "content" when started from the project root); then confirm that later steps resolve the same paths. Changing this path is a portability adjustment and does not by itself recreate the original Linux environment. The committed results are available for inspection without rerunning the experiment. Verification and tests There is no standalone test suite, test runner configuration, or command-line entry point in this checkout. The intended experiment-level verification is the audit in notebook Step 9, together with the recorded result checksums. To verify the files listed in results/checksums.sha256 on Windows PowerShell, run this from the project root: Get-Content ..sha256 | ForEach-Object { $expected, $name = _ -split '+', 2actual = (Get-FileHash (Join-Path . $name) -Algori