Quantifying the benefits of code hints for refactoring deprecated Java APIs

Cristina David; Daniel Kroening; Hanliang Zhang; Pascal Kesseli

REVIEW 3 major objections 6 minor 65 references

Quantifying the benefits of code hints for refactoring deprecated Java APIs

T0 review · 3 major / 6 minor · reviewed 2026-08-11 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Javadoc replacement hints are the enabling factor for automated refactoring of deprecated Java APIs.

desk verdict Real engines, transparent reporting, and a big observed gap—but the causal claim about Javadoc hints rests on a confounded comparison that needs a same-task ablation before it can be believed. read the letter →

arxiv 2412.08041 v4 pith:ORICR2QN submitted 2024-12-11 cs.SE

Cristina David , Pascal Kesseli , Daniel Kroening , Hanliang Zhang This is my paper · ORCID

classification cs.SE

keywords programrefactoringdeprecatedAPIscodehintssynthesislargelanguagemodelsCEGISJavadocJava

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper asks whether automated tools can replace calls to deprecated Java APIs, and how much the replacement suggestion written in Javadoc contributes to that task. It builds two automatic refactoring engines, one symbolic and one neural, and applies them to 236 deprecated methods from the JDK 15 API. The central finding is that code hints are enabling: when the Javadoc names a replacement, even the weaker engine refactors 71% of the tasks successfully, while without a hint the best engine succeeds on at most 14%. If the comparison is fair, the practical consequence is that adding a one-line replacement hint to API documentation is a direct way to make legacy-code migration automatable.

What carries the argument

The carrying mechanism is a counterexample-guided inductive synthesis (CEGIS) loop shared by both engines. A synthesis phase proposes a candidate refactoring, and a verification phase fuzzes for an input on which the original and candidate behave differently; if it finds one, that input is fed back to refine the candidate. For the symbolic engine, the synthesis space is controlled by a seeded component library: the three-phase seeding algorithm starts from constants and instructions in the Javadoc hint, adds realisable generators for required target types, then adds transformers that consume the original inputs. For the neural engine, synthesis is an iterated LLM query whose prompt carries the Javadoc hint, the code snippet, formatting constraints, and past counterexamples. Equivalence is checked against a predicate that compares exceptions, live variables, loaded classes, static fields, and alias equivalence classes, so the reported refactorings are observational equivalences over stack and heap state, not mere textual rewrites.

What would settle it

Rerun the engines on the same call sites after mechanically deleting the @code replacement text from the Javadoc of the hinted benchmarks, keeping the @deprecated tag otherwise intact. If the success rate stays near 71%, hints are not the cause; if it falls toward the 14% no-hint level, the paper's causal claim is confirmed. The symmetric experiment would add a synthetic hint to the no-hint tasks.

Watch

Extended reading notes

Core claim

On the paper's own terms, the discovery is that a Javadoc code hint—a @code block inside a @deprecated tag naming the replacement API—is what makes deprecated-API refactoring tractable for both families of code generators. With hints, the worst of the three engine configurations refactors 71% of benchmarks and the best virtual engine reaches 82%; without hints, the best configuration is at 14%. The engines themselves are a symbolic synthesizer that weaves instructions from a library seeded by types and hints, and a neural synthesizer that prompts an LLM with the Javadoc, the method definition, and any counterexamples. Both depend on the hint, though in different ways: the symbolic engine needs it to prune the component library, while the neural engine uses it as additional context. The paper concludes from this that adding more code hints to Javadoc can boost automation of refactoring.

Load-bearing premise

The causal claim assumes that the with-hint and without-hint benchmark groups are equally hard on average; if methods with documented replacements happen to be simpler to migrate, the 71%-versus-14% gap could reflect task difficulty rather than the hint's contribution.

Editorial extensions

If this is right

On tasks whose Javadoc contains a code hint, all engine configurations refactor at least 71% of the 236-benchmark suite, and the union of engine outputs reaches 82%.
On tasks without code hints, no engine exceeds 14%, so the hint, not the engine choice, dominates whether automation succeeds.
The symbolic engine slightly outperforms the neural engines on hinted tasks while using less compute, indicating type- and hint-guided search can beat large language models in this specialised setting.
A practical policy follows: for deprecated methods that have a replacement, adding an explicit @code hint to the Javadoc should make client-code migration substantially more automatable.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

Editorial inference: a direct ablation—stripping only the @code replacement text from the hinted benchmarks and rerunning the same engines on the same call sites—would test whether the gap is caused by the hint or by a correlation between having a documented replacement and having an easier migration.
Editorial inference: the result suggests that API documentation quality, not model or solver capability, may be the current bottleneck for automated migration, so investment in writing replacement hints could have higher leverage than further engine tuning.
Editorial inference: the seeded-library mechanism should transfer to other languages and frameworks whose deprecation documentation follows a similar 'use X instead' convention, making the hint-extraction step the portability question rather than the synthesis itself.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Bottom line: the paper builds two real refactoring engines, releases their code, and reports a 71–82% vs ≤14% success gap that is almost certainly too large to be pure noise. But the headline comparison rests on a confound—the with-hint and without-hint tasks are different benchmark sets, and there is no same-task ablation where the hint is stripped from the same method. The causal claim that Javadoc hints boost refactoring is plausible but not proven.

What’s new: a component library seeded from parsed Javadoc @code hints, and a systematic measurement on the JDK 15 deprecated API set. That’s a real contribution. The symbolic engine (CEGIS + JQF) and the neural engine (Claude 2.1/3 with iterative counterexample prompting) are both implemented and tested; the paper is transparent about verifier incompleteness (Sections 4.2, 5.2) and counts unsound refactorings it manually found. That honesty is worth credit.

The soft spots are real, and the stress-test note is on target. The 71% vs 14% comparison is not apples-to-apples. For the symbolic engine, the no-hint condition uses a Types-library that the authors built by restricting seeding to the method’s signature; the paper itself admits that Calendar-class generators like getInstance would not be included without the hint. So the symbolic no-hint baseline is partly an artifact of library construction. For the neural engine, the no-hint prompt still includes the full Javadoc (Figure 3), so the LLM only loses the @code-tagged hint, not all replacement information—and the paper notes useful hints appear in prose. Also, the “Best Virtual Engine” comparison mixes engines (worst-with vs best-without), which inflates the apparent effect. No confidence intervals or significance tests are reported, and the with/without split is defined by the authors’ parser.

One minor point: the abstract’s “even the worst engine… drops to at best 14%” obscures that it is comparing different engines’ best conditions, not the same engine with and without hints.

Who’s this for? SE researchers working on automated refactoring, API migration, and documentation-for-code-generation. The artifact is a useful baseline, and the research question matters. A serious referee should engage; the paper is worth reviewing but needs a same-task ablation or a treated-control design, plus basic statistical reporting, before the prescriptive conclusion is justified. My recommendation: send it out, but make clear the confound is the central issue to fix.

Referee Report

3 major / 6 minor

Summary. The paper presents two automated refactoring engines for replacing deprecated Java API methods: a symbolic engine based on type-directed and component-based synthesis, and a neural engine based on Claude LLMs. Both use a CEGIS loop with a fuzzing-based equivalence checker. The evaluation covers 236 deprecated methods from the Oracle JDK 15 deprecated API list, split into benchmarks where Javadoc code hints were extractable and benchmarks without such hints. The headline result is that with code hints, success rates range from 71% to 82%, while without code hints they range from 6% to 14%. The paper concludes that adding code hints to Javadoc would substantially boost automated refactoring of deprecated APIs.

Significance. If the causal claim holds, the result is practically important: it would provide quantitative evidence that a concrete, low-cost documentation practice (adding structured replacement hints to Javadoc) materially improves automated migration of deprecated APIs. The paper also contributes a careful artifact, including two engine families, a fuzzing-based verifier, and a public benchmark derived from the JDK 15 deprecated list. Strengths include the transparency about verifier incompleteness (Sections 4.2, 4.4, 5.2, 6), the manual adversarial review of unsound refactorings, and the availability of the implementation and experiments. However, the central causal interpretation is currently threatened by a task-selection confound: the with-hint and without-hint conditions are evaluated on disjoint benchmark sets, so the reported 71% vs 14% gap may reflect intrinsic task difficulty rather than the benefit of hints.

major comments (3)

[§5.2, Table 1] The headline comparison contrasts two disjoint benchmark sets: tasks where the authors' parser could extract a code hint from the Javadoc versus tasks where it could not. Methods whose deprecation notes document a clean replacement are likely to be intrinsically simpler to refactor than methods without such documentation. The paper provides no same-task ablation that strips the hint from the same benchmark and reruns the engines, so the 71% versus 14% gap could be entirely a task-difficulty effect. This is load-bearing for the abstract's causal claim that 'adding more code hints to Javadoc can hence boost the refactoring.' Please add a condition in which the same tasks are run with the hint removed, or otherwise control for intrinsic difficulty (e.g., through matched pairs of methods with comparable signatures).
[§2.1 and Figure 3] For the neural engine, the 'without code hints' condition still includes the full Javadoc comment in the prompt, so the LLM receives any replacement suggestions written in prose even when the parser failed to extract a structured @code hint. The paper itself acknowledges in §3 (Phase 1) that 'there are scenarios where, while the Javadoc does contain a useful code hint, it is not tagged accordingly with the @code tag.' Thus the neural comparison actually measures the presence of parser-extractable structured hints, not the presence of hints in general. To support the paper's broader conclusion, the no-hint condition should also suppress the @deprecated text from the prompt, or the analysis should be restricted to tasks where the only difference is the structured @code hint.
[§3.1 and §5.2] For the symbolic engine, the no-hint baseline uses the Types-library, which by construction excludes classes that appear only in code hints. The paper states in §3.1 that the Calendar class 'is only mentioned by the code hints and would not be included in the seeding of the Types-library.' Consequently, the symbolic no-hint success rate of 6% is in part an artifact of an intentionally restricted component library, not a measure of what type-directed synthesis could achieve from the type signature alone. The claim that code hints are 'enabling' for the symbolic engine requires a baseline where the same task is, in principle, solvable from types alone (e.g., a broader type-based library, or a control where the hint is replaced by an equivalent non-hint signal such as the textual deprecation reason).

minor comments (6)

[§1 and §5.2] The term 'code hint' is defined conceptually in the introduction as 'sometimes, what can be used in its place,' but the experimental condition is 'code hints could be extracted from the Javadoc.' Please clarify the distinction between the conceptual definition and the operational parser-based criterion, and state this explicitly when reporting the split.
[Table 1] The table header '⌀ runtime' is nonstandard; rename to 'avg. runtime' and add a note that the neural-engine counts are averages over three runs, as described in §5.1.
[§5.1] The sentence 'we bound the search by at most 500 inputs and 5 minutes per verification phase, and at most 2 minutes per synthesis phase' should clarify whether these bounds apply identically to the neural engine's verification calls and to the symbolic engine's fallback to the Types-library.
[§4.1] The curated Mockito-avoidance constructor list is a manual, task-specific artifact; please describe its size and selection criteria, since it could influence the symbolic engine's success on particular benchmarks.
[§6] The 'Threats to validity' section does not discuss the selection confound between hint and no-hint benchmarks; this is a more serious threat than the ones currently listed and should be addressed explicitly.
[Abstract] The phrasing 'even the worst engine correctly refactors 71% of the tasks with code hints, which drops to at best 14% on tasks without' could mislead readers into thinking the same engine achieves 14%; rephrase to make clear that 14% is the best virtual engine without hints.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the 71% versus 14% headline compares observed success rates against the external JDK 15 deprecated-API list, and hint seeding is the experimental treatment rather than a fitted or self-referential prediction.

full rationale

The paper's central claim is empirical, not definitional: with Javadoc code hints, the engines solve 71-82% of tasks, and without hints at best 14%, where correctness is judged by a behavioral equivalence check (fuzzing-based, Section 2.3) independent of whether a hint was present. The symbolic engine's CodeHints-library is literally seeded from the hint (Section 3, Phase 1: 'we add all the constants and instructions from the code hints to the library'), and its no-hint Types-library omits hint-only types (Section 3.1 explicitly concedes that Calendar 'is only mentioned by the code hints and would not be included in the seeding of the Types-library'). That is a disclosed experimental mechanism, not a circular derivation; it is the treatment being studied. The main weakness is external validity: Section 5.2 compares disjoint task sets ('We split our dataset into benchmarks where code hints could be extracted from the Javadoc, and benchmarks without code hints') with no same-task hint-stripped ablation, so task difficulty is a confound for the causal claim that adding hints boosts refactoring. Moreover, Section 3 acknowledges that Javadoc can contain useful hints not tagged with @code, and the neural prompt (Figure 3) supplies the full Javadoc comment even in the without-hint condition, so the no-hint group is not necessarily hint-free. These are validity threats, not circular reasoning: no fitted parameter is renamed as a prediction, and no central premise is justified by a self-citation chain. Self-citations such as [6], [10], [60], and [61] appear only as background and are not load-bearing for the headline result. No circular step can be exhibited, so the circularity score is 0.

Assumptions & free parameters 3 free parameters · 5 assumptions · 0 invented entities

The central empirical claim rests on three kinds of support: (i) the fuzzing-based equivalence check, whose incompleteness the paper documents in Sections 4.2 and 5.2; (ii) the comparability of the with-hint and without-hint benchmark groups, which is assumed but untested and is the main statistical weakness; and (iii) the accuracy of parsed Javadoc hints as replacement semantics. No parameters are fitted to data in the sense of tuning a model to reproduce the result; the hand-chosen budgets and temperature do, however, shape the reported percentages.

free parameters (3)

Fuzzing budgets and timeouts = 500 inputs; 5 min verification; 2 min synthesis
Hand-chosen bounds (Section 5.1); tasks that time out are counted as missed, so these numbers directly shape the reported success percentages.
LLM sampling temperature = 0.2
Chosen in Section 5.1 to reduce randomness; affects the three-run averages behind the neural rows in Table 1.
Curated Mockito-avoidance constructor list = Not enumerated
Manual curation in Section 4.1 (e.g., avoiding collection constructors that take a capacity argument), which changes which benchmarks are fuzzable and hence verifiable.

assumptions (5)

domain assumption Reflection-based observation captures all side effects that matter for equivalence of original and refactored code.
Needed for the equivalence predicate in Section 2.3 and stated in Section 4.2; the paper itself notes it fails for I/O, native methods, and boot-class-loader static state.
domain assumption JQF coverage-guided fuzzing finds a distinguishing input whenever original and candidate refactoring differ observably.
The verification phase in Section 2.2 relies on this; Section 5.2 gives counterexamples where it fails (JViewport#isBackingStoreEnabled, RMIClassLoader#loadClass).
domain assumption The set of deprecated methods with extractable code hints and the set without are comparable in intrinsic refactoring difficulty.
Required for the causal conclusion that hints, not task difficulty, explain the 71 percent versus 14 percent gap; the paper never tests this assumption (Section 5.2).
domain assumption Javadoc @deprecated hints accurately state the intended replacement semantics.
Hints are parsed as Java expressions and used as seeds for the component library (Section 3, Phase 1).
domain assumption Value equality implemented by reflection over field chains, ignoring user-written equals unless strict criteria are met, captures semantic equivalence.
Definition 1 and Definition 2 in Section 2.3; the authors explicitly distrust user-written equals implementations.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Quantifying the benefits of code hints for refactoring deprecated Java APIs." pith.science (2026). https://pith.science/paper/ORICR2QN

@misc{pith2026241208041,
  author       = {Pith},
  title        = {Pith review of: Quantifying the benefits of code hints for refactoring deprecated Java APIs},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/ORICR2QN}},
  note         = {Machine review of arXiv:2412.08041}
}

read the original abstract

When done manually, refactoring legacy code in order to eliminate uses of deprecated APIs is an error-prone and time-consuming process. In this paper, we investigate to which degree refactorings for deprecated Java APIs can be automated, and quantify the benefit of Javadoc code hints for this task. To this end, we build a symbolic and a neural engine for the automatic refactoring of deprecated APIs. The former is based on type-directed and component-based program synthesis, whereas the latter uses LLMs. We applied our engines to refactor the deprecated methods in the Oracle JDK 15. Our experiments show that code hints are enabling for the automation of this task: even the worst engine correctly refactors 71% of the tasks with code hints, which drops to at best 14% on tasks without. Adding more code hints to Javadoc can hence boost the refactoring of code that uses deprecated APIs.

Figures

Figures reproduced from arXiv: 2412.08041 by the authors.

**Figure 1.** Deprecated method example. Refactoring code that relies on deprecated APIs presents additional challenges. For instance, the code to be refactored might be using abstract classes and abstract methods, and it may not be obvious how to subclass from the code to be refactored (e.g. engineGetParameter in java . security . SignatureSpi). It may also call methods that, while not abstract, must be overridden by subclasse… view at source ↗

**Figure 2.** Code hints for the running example. Manual refactoring of deprecated APIs is a time-consuming and error-prone process. Therefore, in this paper, we investigate the automatic generation of refactorings for deprecated APIs. While our primary emphasis is on refactoring deprecated methods, the same techniques can be extended to handle deprecated fields and classes. When deprecating a field, method, or class, the @Depre… view at source ↗

**Figure 3.** LLM Prompt Template. any guarantees that the counterexamples were actually taken into consideration. 2.2 Verification phase This is exactly the same for the two approaches. We are provided with a candidate refactoring 2 and we must check whether there exists any input ® for which the original code and the candidate refactoring are not observationally equivalent. To do this, we build the following Verify method, whic… view at source ↗

Figures from the paper (2 more)

**Figure 4.** Figure 4: Javadoc hint example. realisable as the library doesn’t contain any generator for Calendar. Consequently, Calendaris added to target_types, resulting in: target_types = {int, Calendar}. Definition 3 (Realisable method). Method i is realisable iff ∀ ∈ required_types(). …

**Figure 5.** Figure 5: Seeding algorithm for the CodeHints-library [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

65 extracted references · 38 canonical work pages

[1]

[n. d.]. Claude. https://www.anthropic.com/index/in troducing-claude

work page
[2]

Alessandro Abate, Cristina David, Pascal Kesseli, Dani el Kroening, and Eliz- abeth Polgreen. 2018. Counterexample Guided Inductive Syn thesis Mod- ulo Theories. In Computer Aided Veriﬁcation - 30th International Conferenc e, CA V 2018, Held as Part of the Federated Logic Conference, FloC 2018, Oxford, UK, July 14-17, 2018, Proceedings, Part I (Lecture No...

doi:10.1007/978-3-319-96145-3_15 2018
[3]

Alvin Cheung, Armando Solar-Lezama, and Samuel Madden. 2013. Optimizing database-backed applications with query synthesis. In Conference on Program- ming Language Design and Implementation, PLDI . 3–14

work page 2013
[4]

Giakoumakis, Vassilis E

Aikaterini Christopoulou, E.A. Giakoumakis, Vassilis E. Zafeiris, and Soukara Vasiliki. 2012. Automated refactoring to the Strategy design pattern. Information and Software Technology 54, 11 (2012), 1202 – 1214

work page 2012
[5]

James R Cordy, Thomas R Dean, Andrew J Malton, and Kevin A S chneider. 2002. Source transformation in software engineering using the TX L transformation system. Information and Software Technology 44, 13 (2002), 827 – 837

work page 2002
[6]

Cristina David, Pascal Kesseli, and Daniel Kroening. 20 17. Kayak: Safe Seman- tic Refactoring to Java Streams. CoRR abs/1712.07388 (2017). arXiv:1712.07388 http://arxiv.org/abs/1712.07388

work page Pith review arXiv 2017
[7]

Yangruibo Ding, Zijian Wang, Wasi Ahmad, Murali Krishna Ra- manathan, Ramesh Nallapati, Parminder Bhatia, Dan Roth, an d /Q_uantifying the benefits of code hints for refactoring deprecated Java APIs FSE Companion ’25, June 23–28, 2025, Trondheim, Norway Bing Xiang. 2024. CoCoMIC: Code completion by jointly modeling in-ﬁle and cross-ﬁle context. In LREC-CO...

work page 2025
[9]

Mehmet Emre, Ryan Schroeder, Kyle Dewey, and Ben Hardeko pf. 2021. Trans- lating C to safer Rust. Proc. ACM Program. Lang. 5, OOPSLA, Article 121 (Oct. 2021), 29 pages. doi:10.1145/3485498

doi:10.1145/3485498 2021

Show all 65 references

[10]

Hasan Ferit Eniser, Hanliang Zhang, Cristina David, Me ng Wang, Maria Chris- takis, Brandon Paulsen, Joey Dodds, and Daniel Kroening. 20 24. Towards Trans- lating Real-World Code with LLMs: A Study of Translating to R ust. CoRR abs/2405.11514 (2024). doi:10.48550/ARXIV.2405.11...

2024 doi arXiv
[11]

Mattia Fazzini, Qi Xin, and Alessandro Orso. 2019. Auto mated API-usage update for Android apps. In Proceedings of the 28th ACM SIGSOFT Interna- tional Symposium on Software Testing and Analysis, ISSTA 20 19, Beijing, China, July 15-19, 2019 , Dongmei Zhang and Anders Møller (...

2019
[12]

Yu Feng, Ruben Martins, Yuepeng Wang, Isil Dillig, and T homas W. Reps. 2017. Component-based synthesis for complex APIs. In Proceedings of the 44th ACM SIGPLAN Symposium on Principles of Programming Languages, POPL 2 017, Paris, France, January 18-20, 2017 , Giuseppe Castagna...

2017
[13]

Feser, Swarat Chaudhuri, and Isil Dillig

John K. Feser, Swarat Chaudhuri, and Isil Dillig. 2015. Synthesizing data struc- ture transformations from input-output examples. In Proceedings of the 36th ACM SIGPLAN Conference on Programming Language Design and Imp lementa- tion, Portland, OR, USA, June 15-17, 2015, David ...

2015
[14]

Lyle Franklin, Alex Gyori, Jan Lahoda, and Danny Dig. 2013. LAMBDAFICATOR: from imperative to functional programming through automat ed refactoring. In 35th International Conference on Software Engineering, IC SE ’13, San Francisco, CA, USA, May 18-26, 2013 . 1287–1290. doi:10...

2013
[15]

Fuhrer, Frank Tip, Adam Kiezun, Julian Dolby, and Markus Keller

Robert M. Fuhrer, Frank Tip, Adam Kiezun, Julian Dolby, and Markus Keller
[16]

Sumit Gulwani, Susmit Jha, Ashish Tiwari, and Ramarath nam Venkatesan. 2011. Synthesis of loop-free programs. In Proceedings of the 32nd ACM SIGPLAN Con- ference on Programming Language Design and Implementation, PLDI 2011, San Jose, CA, USA, June 4-8, 2011 , Mary W. Hall and ...

2011
[17]

Daya Guo, Qihao Zhu, Dejian Yang, Zhenda Xie, Kai Dong, W entao Zhang, Guanting Chen, Xiao Bi, Y. Wu, Y. K. Li, Fuli Luo, Yingfei Xion g, and Wenfeng Liang. 2024. DeepSeek-Coder: When the Large Language Model Meets Program- ming – The Rise of Code Intelligence. arXiv:2401.1419...

2024 arXiv
[18]

Alex Gyori, Lyle Franklin, Danny Dig, and Jan Lahoda. 20 13. Crossing the gap from imperative to functional programming through refacto ring.. In ESEC/SIG- SOFT FSE. ACM, 543–553
[19]

Haryono, Ferdian Thung, Hong Jin Kang, Luca s Serrano, Gilles Muller, Julia Lawall, David Lo, and Lingxiao Jiang

Stefanus A. Haryono, Ferdian Thung, Hong Jin Kang, Luca s Serrano, Gilles Muller, Julia Lawall, David Lo, and Lingxiao Jiang. 2020. Au tomatic Android Deprecated-API Usage Update by Learning from Single Update d Example. In ICPC’20: 28th International Conference on Program Com...

2020
[20]

Haryono, Ferdian Thung, David Lo, Lingxiao Jiang, Julia Lawall, Hong Jin Kang, Lucas Serrano, and Gilles Muller

Stefanus A. Haryono, Ferdian Thung, David Lo, Lingxiao Jiang, Julia Lawall, Hong Jin Kang, Lucas Serrano, and Gilles Muller. 2022. AndroEvolve: automated Android API update with data ﬂow analysis and variable denor malization. Em- pir. Softw. Eng. 27, 3 (2022), 73. doi:10.1007...

2022 doi
[21]

Wenpin Hou and Zhicheng Ji. 2024. Comparing large langu age models and hu- man programmers for generating programming code. arXiv:24 03.00894 [cs.SE] https://arxiv.org/abs/2403.00894

2024 arXiv
[22]

Kaifeng Huang, Bihuan Chen, Linghao Pan, Shuai Wu, and X in Peng. 2021. REPFINDER: Finding Replacements for Missing APIs in Librar y Update. In 36th IEEE/ACM International Conference on Automated Softw are Engineer- ing, ASE 2021, Melbourne, Australia, November 15-19, 2021 . I...

2021
[23]

Ming-Yee Iu, Emmanuel Cecchet, and Willy Zwaenepoel. 2 010. JReq: Database Queries in Imperative Languages. In Compiler Construction (CC) . 84–103
[24]

Izadi, J

M. Izadi, J. Katzy, T. van Dam, M. Otten, R. Popescu, and A . van Deursen. 2024. Language Models for Code Completion: A Pract ical Eval- uation. In 2024 IEEE/ACM 46th International Conference on Software En gi- neering (ICSE) . IEEE Computer Society, Los Alamitos, CA, USA, 956...

2024
[25]

Sang-Uk Jeon, Joon-Sang Lee, and Doo-Hwan Bae. 2002. An automated refactor- ing approach to design pattern-based program transformations in Java programs. In Asia-Paciﬁc Software Engineering Conference (APSEC) . 337–345

2002
[27]

Juyong Jiang, Fan Wang, Jiasi Shen, Sungju Kim, and Sung hun Kim. 2024. A Sur- vey on Large Language Models for Code Generation. arXiv:240 6.00515 [cs.CL] https://arxiv.org/abs/2406.00515

2024 arXiv
[28]

Juyong Jiang, Fan Wang, Jiasi Shen, Sungju Kim, and Sung hun Kim. 2024. A Sur- vey on Large Language Models for Code Generation. arXiv:240 6.00515 [cs.CL]

2024
[29]

Ernst, and Wil liam G

Yoshio Kataoka, David Notkin, Michael D. Ernst, and Wil liam G. Griswold. 2001. Automated Support for Program Refactoring Using Invariant s. In Proceedings of the IEEE International Conference on Software Maintenan ce (ICSM ’01) . IEEE Computer Society

2001
[30]

Susumu Katayama. 2005. Systematic search for lambda ex pressions. In Revised Selected Papers from the Sixth Symposium on Trends in Functio nal Programming, TFP 2005, Tallinn, Estonia, 23-24 September 2005 (Trends in Functional Program- ming, Vol. 6), Marko C. J. D. van Eekelen...

2005
[31]

Raﬃ Khatchadourian, Jason Sawin, and Atanas Rountev. 2 007. Automated Refac- toring of Legacy Java Software to Enumerated Types. In Software Maintenance,
[32]

Ernst, Frank Tip, and Robert M

Adam Kiezun, Michael D. Ernst, Frank Tip, and Robert M. F uhrer. 2007. Refac- toring for Parameterizing Java Classes. In 29th International Conference on Soft- ware Engineering (ICSE 2007), Minneapolis, MN, USA, May 20- 26, 2007. 437–446. doi:10.1109/ICSE.2007.70

2007 doi
[33]

Seonah Lee, Rongxin Wu, Shing-Chi Cheung, and Sungwon K ang. 2021. Automatic Detection and Update Suggestion for Outdated API Names in Documentation. IEEE Trans. Software Eng. 47, 4 (2021), 653–675. doi:10.1109/TSE.2019.2901459

2021
[34]

Anton Lozhkov, Raymond Li, Loubna Ben Allal, Federico C assano, Joel Lamy- Poirier, Nouamane Tazi, Ao Tang, Dmytro Pykhtar, Jiawei Liu , Yuxiang Wei, Tianyang Liu, Max Tian, Denis Kocetkov, Arthur Zucker, Youn es Belkada, Zi- jian Wang, Qian Liu, Dmitry Abulkhanov, Indraneil P...

2024 arXiv
[35]

Justin Lubin, Nick Collins, Cyrus Omar, and Ravi Chugh. 2020. Program sketch- ing with live bidirectional evaluation. Proc. ACM Program. Lang. 4, ICFP (2020), 109:1–109:29. doi:10.1145/3408991

2020 doi
[36]

Lincoln Murr, Morgan Grainger, and David Gao. 2023. Tes ting LLMs on Code Generation with Varying Levels of Prompt Speciﬁcity. arXiv :2311.07599 [cs.SE] https://arxiv.org/abs/2311.07599

2023 arXiv
[37]

Wang, and Xi Victoria Lin

Ansong Ni, Srini Iyer, Dragomir Radev, Ves Stoyanov, Wen-tau Yih, Sida I. Wang, and Xi Victoria Lin. 2023. LEVER: Learning to verify languag e-to-code genera- tion with execution. In Proceedings of the 40th International Conference on Ma- chine Learning (, Honolulu, Hawaii, US...

2023
[38]

O’Keeﬀe and M.O

M. O’Keeﬀe and M.O. Cinnéide. 2008. Search-based refac toring: an empirical study. Journal of Software Maintenance and Evolution: Research an d Practice 20, 5 (2008), 345–364

2008
[39]

O’Keeﬀe and M.O

M. O’Keeﬀe and M.O. Cinnéide. 2008. Search-based refac toring for software maintenance. Journal of Systems and Software 81, 4 (2008), 502 – 516

2008
[40]

OpenAI, Josh Achiam, Steven Adler, Sandhini Agarwal, L ama Ahmad, Ilge Akkaya, Florencia Leoni Aleman, Diogo Almeida, Janko Alten schmidt, Sam Alt- man, Shyamal Anadkat, Red Avila, Igor Babuschkin, Suchir Ba laji, Valerie Bal- com, Paul Baltescu, Haiming Bao, Mohammad Bavarian...

2025
[41]

Oracle. 2020. Deprecated List (Java SE 15 & JDK 15) . https://docs.oracle.com/en/java/javase/15/docs/api/deprecated-list.html

2020
[42]

Peter-Michael Osera and Steve Zdancewic. 2015. Type-a nd-example-directed program synthesis. In Proceedings of the 36th ACM SIGPLAN Conference on Programming Language Design and Implementation, Portland, O R, USA, June 15-17, 2015 , David Grove and Stephen M. Blackburn (Eds.)....

2015
[43]

Rohan Padhye, Caroline Lemieux, and Koushik Sen. 2019. JQF: coverage-guided property-based testing in Java. In Proceedings of the 28th ACM SIGSOFT Interna- tional Symposium on Software Testing and Analysis, ISSTA 20 19, Beijing, China, July 15-19, 2019 , Dongmei Zhang and Ande...

2019
[44]

Rangeet Pan, Ali Reza Ibrahimzada, Rahul Krishna, Divy a Sankar, Lam- bert Pouguem Wassi, Michele Merler, Boris Sobolev, Raju Pav uluri, Saurabh Sinha, and Reyhaneh Jabbarvand. 2024. Lost in Translation: A Study of Bugs Introduced by Large Language Models while Translating Cod...

2024
[45]

Jeﬀ H. Perkins. 2005. Automatically generating refact orings to support API evo- lution. In Proceedings of the 2005 ACM SIGPLAN-SIGSOFT Workshop on Progra m Analysis For Software Tools and Engineering, PASTE’05, Lis bon, Portugal, Septem- ber 5-6, 2005 , Michael D. Ernst and T...

2005
[46]

Baptiste Rozière, Jonas Gehring, Fabian Gloeckle, Ste n Sootla, Itai Gat, Xiao- qing Ellen Tan, Yossi Adi, Jingyu Liu, Romain Sauvestre, Tal Remez, Jérémy Rapin, Artyom Kozhevnikov, Ivan Evtimov, Joanna Bitton, Ma nish Bhatt, Cris- tian Canton Ferrer, Aaron Grattaﬁori, Wenhan ...

2024 arXiv
[47]

Max Schäfer, Julian Dolby, Manu Sridharan, Emina Torla k, and Frank Tip. 2010. Correct Refactoring of Concurrent Java Code. In ECOOP 2010 – Object-Oriented Programming, Theo D’Hondt (Ed.). Springer Berlin Heidelberg, Berlin, H eidel- berg, 225–249

2010
[48]

Armando Solar-Lezama, Christopher Grant Jones, and Ra stislav Bodík. 2008. Sketching concurrent data structures. In Proceedings of the ACM SIGPLAN 2008 Conference on Programming Language Design and Implementati on, Tucson, AZ, USA, June 7-13, 2008 , Rajiv Gupta and Saman P. Am...

2008
[49]

Friedrich Steimann. 2011. Constraint-Based Model Ref actoring. In Model Driven Engineering Languages and Systems: 14th Internatio nal Conference (MOD- ELS), Jon Whittle, Tony Clark, and Thomas Kühne (Eds.). Springer , 440–454. doi:10.1007/978-3-642-24485-8_32

2011 doi
[50]

Friedrich Steimann, Christian Kollee, and Jens von Pil grim. 2011. A Refactor- ing Constraint Language and Its Application to Eiﬀel. In ECOOP 2011 – Object- Oriented Programming: 25th European Conference , Mira Mezini (Ed.). Springer, 255–280. doi:10.1007/978-3-642-22655-7_13

2011 doi
[51]

Friedrich Steimann and Jens von Pilgrim. 2012. Constra int-Based Refactoring with Foresight. In ECOOP 2012 – Object-Oriented Program- ming: 26th European Conference , James Noble (Ed.). Springer, 535–559. doi:10.1007/978-3-642-31057-7_24

2012 doi
[52]

Zilu Tang, Mayank Agarwal, Alexander Shypula, Bailin W ang, Derry Wijaya, Jie Chen, and Yoon Kim. 2023. Explain-then-translate: an an alysis on improving program translation with self-generated explanations. In Findings of the Associa- tion for Computational Linguistics: EMNLP...

2023
[53]

Hugo Touvron, Louis Martin, Kevin Stone, Peter Albert, Amjad Almahairi, Yas- mine Babaei, Nikolay Bashlykov, Soumya Batra, Prajjwal Bhargava, Shruti Bhos- ale, Dan Bikel, Lukas Blecher, Cristian Canton Ferrer, MoyaChen, Guillem Cucu- rull, David Esiobu, Jude Fernandes, Jeremy ...

2023
[54]

Eelco Visser. 2004. Program Transformation with Stratego/XT. Rules, Strategie s, Tools, and Systems in Stratego/XT 0.9 . Technical Report UU-CS-2004-011. De- partment of Information and Computing Sciences, Utrecht Un iversity

2004
[55]

Wei Wu, Yann-Gaël Guéhéneuc, Giuliano Antoniol, and Mi ryung Kim. 2010. AURA: a hybrid approach to identify framework evolution. In Proceedings of the 32nd ACM/IEEE International Conference on Software Eng ineering - Vol- ume 1, ICSE 2010, Cape Town, South Africa, 1-8 May 2010...

2010
[56]

Xu, Uri Alon, Graham Neubig, and Vincent J

Frank F. Xu, Uri Alon, Graham Neubig, and Vincent J. Hell endoorn. 2022. A Systematic Evaluation of Large Language Models of Code. CoRR abs/2202.13169 (2022). arXiv:2202.13169 https://arxiv.org/abs/2202.1 3169

2022 arXiv
[57]

Masaomi Yamaguchi, Kazutaka Matsuda, Cristina David, and Meng Wang. 2021. Synbit: synthesizing bidirectional programs using unidir ectional sketches. Proc. ACM Program. Lang. 5, OOPSLA (2021), 1–31. doi:10.1145/3485482

2021 doi
[58]

Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Oﬁr Press

John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Oﬁr Press. 2024. SWE-agent: Agent- Computer Inter- faces Enable Automated Software Engineering. arXiv:2405. 15793 [cs.SE]

2024
[59]

Fengji Zhang, Bei Chen, Yue Zhang, Jacky Keung, Jin Liu, Daoguang Zan, Yi Mao, Jian-Guang Lou, and Weizhu Chen. 2023. RepoCoder: Re pository- Level Code Completion Through Iterative Retrieval and Gene ration. In The 2023 Conference on Empirical Methods in Natural Languag e Pro...

2023
[60]

Hanliang Zhang, Cristina David, Wang Meng, Brandon Pau lsen, and Daniel Kroening. 2025. Scalable, Validated Code Translation of En tire Projects using Large Language Models. Programming Language Design and Implementation (PLDI) (2025)

2025
[61]

Hanliang Zhang, Cristina David, Yijun Yu, and Meng Wang . 2023. Ownership Guided C to Rust Translation. In Computer Aided Veriﬁcation - 35th International Conference, CA V 2023, Paris, France, July 17-22, 2023, Proceedings, Part III (Lecture Notes in Computer Science, Vol. 139...

2023 doi
[62]

Shuyan Zhou, Uri Alon, Sumit Agarwal, and Graham Neubig . 2023. Code- BERTScore: Evaluating Code Generation with Pretrained Models of Code. CoRR abs/2302.05527 (2023). doi:10.48550/arXiv.2302.05527 a rXiv:2302.05527

2023 doi arXiv
[63]

Qihao Zhu, Qingyuan Liang, Zeyu Sun, Yingfei Xiong, Lu Z hang, and Shengyu Cheng. 2024. GrammarT5: Grammar-Integrated Pretrained En coder-Decoder Neural Model for Code. In Proceedings of the IEEE/ACM 46th International Conference on Software Engineering (, Lisbon, Portugal,) (...

2024
[148]

doi:10.1145/1375581.1375599
[1788]

doi:10.18653/v1/2023.ﬁndings-emnlp.119

2023 doi
[2005]

In ECOOP 2005 - Object-Oriented Programming, 19th European Con ference, Glasgow, UK, July 25-29, 2005, Proceedings

Eﬃciently Refactoring Java Applications to Use Gener ic Libraries. In ECOOP 2005 - Object-Oriented Programming, 19th European Con ference, Glasgow, UK, July 25-29, 2005, Proceedings . 71–96. doi:10.1007/11531142_4

2005 doi
[2007]

IEEE International Conference on

ICSM 2007. IEEE International Conference on . 224–233

2007

Pith tools

Reviewed August 11, 2026 · model on record in the stance chip above.

[1] [1]

[n. d.]. Claude. https://www.anthropic.com/index/in troducing-claude

work page

[2] [2]

Alessandro Abate, Cristina David, Pascal Kesseli, Dani el Kroening, and Eliz- abeth Polgreen. 2018. Counterexample Guided Inductive Syn thesis Mod- ulo Theories. In Computer Aided Veriﬁcation - 30th International Conferenc e, CA V 2018, Held as Part of the Federated Logic Conference, FloC 2018, Oxford, UK, July 14-17, 2018, Proceedings, Part I (Lecture No...

doi:10.1007/978-3-319-96145-3_15 2018

[3] [3]

Alvin Cheung, Armando Solar-Lezama, and Samuel Madden. 2013. Optimizing database-backed applications with query synthesis. In Conference on Program- ming Language Design and Implementation, PLDI . 3–14

work page 2013

[4] [4]

Giakoumakis, Vassilis E

Aikaterini Christopoulou, E.A. Giakoumakis, Vassilis E. Zafeiris, and Soukara Vasiliki. 2012. Automated refactoring to the Strategy design pattern. Information and Software Technology 54, 11 (2012), 1202 – 1214

work page 2012

[5] [5]

James R Cordy, Thomas R Dean, Andrew J Malton, and Kevin A S chneider. 2002. Source transformation in software engineering using the TX L transformation system. Information and Software Technology 44, 13 (2002), 827 – 837

work page 2002

[6] [6]

Cristina David, Pascal Kesseli, and Daniel Kroening. 20 17. Kayak: Safe Seman- tic Refactoring to Java Streams. CoRR abs/1712.07388 (2017). arXiv:1712.07388 http://arxiv.org/abs/1712.07388

work page Pith review arXiv 2017

[7] [7]

Yangruibo Ding, Zijian Wang, Wasi Ahmad, Murali Krishna Ra- manathan, Ramesh Nallapati, Parminder Bhatia, Dan Roth, an d /Q_uantifying the benefits of code hints for refactoring deprecated Java APIs FSE Companion ’25, June 23–28, 2025, Trondheim, Norway Bing Xiang. 2024. CoCoMIC: Code completion by jointly modeling in-ﬁle and cross-ﬁle context. In LREC-CO...

work page 2025

[8] [9]

Mehmet Emre, Ryan Schroeder, Kyle Dewey, and Ben Hardeko pf. 2021. Trans- lating C to safer Rust. Proc. ACM Program. Lang. 5, OOPSLA, Article 121 (Oct. 2021), 29 pages. doi:10.1145/3485498

doi:10.1145/3485498 2021