PaperlayerView exact revision on arXiv

Source-linked AI summary

AST-Based Automated Elimination of break and continue Statements in Java Code

Andrés Juárez, José Chicano, Rubén Saborido

arXiv:2609.27627v1cs.SE

TL;DR

Explicit loop jumps can prevent automated Extract Method refactoring. This work rewrites Java loops through AST manipulation and boolean flags; evaluation reports successful compilation and behavioral preservation across transformed methods, plus newly feasible extractions.

  • Problem

    Explicit jumps targeting loops outside a selected block constrain automated Extract Method refactoring, limiting downstream restructuring of complex methods.

    Source: §2.1 · p. 2, §2.5 · p. 3

  • Method

    An Eclipse JDT AST transformation replaces break and continue with boolean state variables and conditional control structures while preserving program semantics.

    Source: §2.2 · p. 2, §9 · p. 8

  • Results

    139 transformed files compiled without syntactic or type errors and preserved behavior; extraction succeeded in 10 cases where the external tool initially returned NO SOLUTION.

    Source: §6.2 · p. 6, §7.3 · p. 7

  • Takeaways & Limitations

    The transformation provides an enabling step for subsequent automated method extraction and maintainability optimization.

    Source: §2.5 · p. 3, §9 · p. 8

    Runtime CPU and memory overhead from additional boolean-flag evaluations was not measured, though the authors expect it to be negligible.

    Source: §9.3 · p. 8

Abstract

from arXiv · show

This work presents the development of an automatic refactoring tool for Java code built on top of the Eclipse JDT API. The proposed approach transforms control structures containing break and continue statements within different types of loops into semantically equivalent constructs that avoid their explicit use. To achieve this, auxiliary boolean variables are introduced to restructure the control flow while preserving the original program behavior. The main objective of this transformation is to improve code structure and enable the application of subsequent automated refactorings, particularly those based on the Extract Method operation, which are typically restricted by the presence of jump statements. The implementation relies on the analysis and rewriting of the Abstract Syntax Tree (AST), ensuring semantic equivalence in all addressed scenarios. The tool was validated through 54 manually designed test cases and 151 units tests, all of which produced satisfactory results. In addition, it was applied to 139 methods from seven open-source projects, generating code without compilation errors and preserving the original behavior as verified by the projects' test suites. The results demonstrate that the proposed approach safely automates the restructuring of code containing break and continue statements, facilitating further evolution and structural analysis.

1 Introduction

Maintenance consumes substantial engineering effort, while explicit loop jumps obstruct automated Extract Method refactoring; the paper introduces an AST-based plugin to remove those jumps and support later refactoring.

1 Introduction

  • Maintenance represents 50%–75% of engineering effort, and over 80% of code modifications occur in 20% of system methods.The introduction links maintainability and readability with preventing defects and reducing developer cognitive friction.Source: §1 · p. 1

1.1 Objectives and Contributions

  • The Eclipse JDT plugin replaces break and continue across Java loop constructs with semantically equivalent, flag-driven conditional blocks.Its stated purpose is to enable downstream Extract Method refactoring.Source: §1.1 · p. 1
  • 139 methods across seven projects yielded 100% syntactic correctness, 100% behavioral equivalence, and a 58% average SSCC reduction after automated method extraction.These are the empirical results stated among the paper’s primary contributions.Source: §1.1 · p. 1

1.2 Document Organization

  • The paper is organized around background, transformation methodology, empirical evaluation, maintainability implications, and conclusions with validity threats and future work.The introduction identifies the relevant sections as Sections 2, 3, 5, 8, and 9.Source: §1.2 · pp. 1–2

2 Related Work and Background

The background connects control-flow complexity to barriers in automated refactoring, motivating AST-based jump elimination as an intermediate step toward method extraction.

2 Related Work and Background

  • Code refactoring restructures existing code without changing external behavior, aiming to improve internal structure, readability, and maintainability.The background relates control-flow clarity to automated transformations and long-term maintainability.Source: §2 · p. 2

2.1 Cognitive Complexity and Refactoring Barriers

  • Explicit break and continue statements can block Extract Method when they target loops outside a selected block, making semantic-preserving jump elimination a prerequisite for downstream refactoring.Extract Method moves nested blocks into helper methods and removes their nesting penalty in the caller.Source: §2.1 · p. 2

2.2 AST-Based Control Flow Transformations

  • AST rewriting supports loop conversion, conditional block wrapping, and auxiliary state insertion while preserving execution paths, side effects, termination conditions, and exception propagation order.The paper contrasts structural AST manipulation with raw-text rewriting, which risks invalid code and cannot reliably distinguish syntactic roles.Source: §2.2 · p. 2

2.3 Eclipse JDT Infrastructure

  • Eclipse JDT provides AST access and rewrite facilities used to traverse nodes, inspect scopes and types, and stage structural mutations while updating bindings and variable scopes.The infrastructure is described as maintaining syntactic validity and source-layout conventions during multi-pass rewrites.Source: §2.3 · p. 2

2.4 Related Work and Limitations of Existing Tools

  • Existing analysis tools flag complexity but leave restructuring to developers, while IDE refactorings abort on jumps; prior work found many unrefactored methods blocked by break or continue.The paper proposes an AST-driven plugin and a normalization stage to expand the methods amenable to later extraction.Source: §2.4 · pp. 2–3, §2.5 · p. 3

2.5 Need and Contributions of this Work

  • The paper’s validation plan combines 54 analytical trace cases, 151 unit tests with 99% instruction coverage, and evaluation on 139 methods from seven open-source projects.The stated empirical contribution measures semantic preservation and interaction with automated Extract Method tools.Source: §2.5 · p. 3

3 Methodology: Transformation Framework

The framework detects loop-targeted jumps, analyzes loop and exception context, and replaces abrupt transfers with boolean state while restructuring loop bodies to preserve execution flow.

3 Methodology: Transformation Framework

  • The applied methodology iteratively formalizes rules, implements AST visitors, validates syntax, and verifies semantics through automated tests.The framework operates on Java CompilationUnit ASTs using Eclipse JDT.Source: §3 · p. 3

3.1.1 Formal Transformation Model.

  • For break, a loop-scoped stay flag is conjoined with the loop condition and later body statements are guarded; for continue, a per-iteration keep flag guards subsequent instructions.The respective jumps become assignments setting their flag to false.Source: §3.1.1 · p. 3

3.1.2 Taxonomy of Supported Scenarios.

  • Condition-based loops use the model directly, sharing flags for multiple jumps but allocating independent flags for nested loops.Traditional for loops are normalized to while loops, and foreach loops are converted to iterator-driven while loops.Source: §3.1.2 · p. 4

3.1.3 Exception Handling and Multi-Variable Control.

  • A finally clause needs independent state tracking because Java executes finally before loop exit; the outer condition combines flags for try and finally scopes with the loop condition.For nested try-catch-finally structures, the engine allocates a per-scope tuple of control variables managed on a dynamic stack.Source: §3.1.3 · p. 4

3.1.4 Complex

  • The tool excludes the rare case where an exception in an inner finally suppresses a pending break caught by an outer catch.Modeling this interaction would require global control-flow restructuring beyond local-scope transformation.Source: §3.1.4 · p. 4

4 Architecture and Implementation

The implementation separates AST inspection from mutation in a multi-pass pipeline, retaining nested blocks to preserve variable scope and AST consistency.

4.1 Multi-Pass Transformation Pipeline

  • A single-pass rewrite proved insufficient because structural changes alter statement offsets, scope boundaries, and AST parent-child relationships.The implementation therefore uses a five-phase pipeline to separate inspection from mutation.Source: §4.1 · p. 4
  • The pipeline first converts for and foreach loops containing jumps to while loops, then annotates loop targets, finally scopes, and structural properties without modifying the AST.These operations are the first two phases of the pipeline.Source: §4.1 · p. 4
  • After body restructuring, the annotators run again to recompute control paths and variable-allocation metadata on the modified tree.The restructuring wraps statements following jumps in nested if blocks to preserve local variable scopes.Source: §4.1 · p. 4
  • The final phase introduces stay and keep variables, updates loop conditions, substitutes jumps with flag assignments, and applies changes through JDT’s ASTRewrite API.Source: §4.1 · p. 4

4.2 Architectural Decoupling and Scope Preservation

  • The implementation retains nested if blocks because flattening consecutive conditions can restrict local-variable scope and cause compilation errors.Separating structural reorganization from semantic variable injection also avoids circular dependencies and maintains AST consistency.Source: §4.2 · pp. 4–5

5 Empirical Evaluation Setup and Validation

The evaluation tested syntactic validity, semantic equivalence, structural correctness, and robustness across open-source software. It combined designed trace cases, automated unit tests, and project-level checks.

5.1 Validation Methodology and Test Suite

  • 54 manually engineered trace cases and 151 JUnit tests checked equivalence, AST conversions, compilation, output behavior, and safe non-intervention on malformed ASTs.The trace cases covered loop types, nesting, combined jumps, and try-catch-finally handling; the unit tests also checked structural conversions.Source: §5.1 · p. 5

5.2 Open-Source Benchmark Dataset

  • 139 methods from seven open-source projects were checked against native test suites; all seven of 22 MOEAFramework tests exercising transformed methods passed, as did suites in jMetal and fastjson.The 22-test count refers to MOEAFramework, where seven native tests directly exercised the refactored methods.Source: §5.2 · p. 5

5.3 Validation Metrics and Infrastructure

  • 99% instruction coverage and 90% branch coverage were achieved across the plugin’s transformation pipeline.Experiments used Java SE 21, Eclipse IDE (2024-12), Maven, JUnit, and JaCoCo.Source: §5.3 · p. 5, Table 1 · p. 5

6 Functional Validation and Empirical Results

Functional evaluation examined unit-test coverage, production-project transformations, and edge cases that prompted changes to the transformation engine.

6.1 Coverage and Unit Test Performance

  • 151 automated unit tests passed, with 99% instruction coverage and 90% branch coverage; uncovered branches were defensive null-check fallbacks for malformed ASTs.Coverage was 2,614 of 2,628 instructions and 250 of 276 branches.Source: §6.1 · p. 6

6.2 Evaluation on Open-Source Projects

  • All 139 transformed files compiled without syntactic or type errors, and native third-party test suites confirmed behavioral preservation; over 96% of candidate control flows were processed.Non-transformed cases were limited to switch-based breaks, labeled jumps, or null type bindings.Source: §6.2 · p. 6

6.3 Identified Edge Cases and Bug Fixes

  • Flattening consecutive if blocks caused local-variable visibility errors, so the implementation retained nested if blocks to preserve lexical scope.The original variables remained visible across blocks belonging to the same scope.Source: §6.3 · p. 6
  • In for-to-while desugaring, moving the updater to the body’s end could cause an infinite loop with continue, so it is placed last outside conditional blocks.The rewriter tags updater expressions and applies this placement when continue is present.Source: §6.3 · p. 6
  • When wildcard imports left foreach target types unresolved, the tool now aborts rather than inject an iterator unsafely.Source: §6.3 · p. 6
  • Nested try-catch-finally blocks with jumps required more than two control flags per loop, prompting dynamically allocated flags scoped per finally block.Source: §6.3 · p. 6

7 Impact on Cognitive Complexity and Method Extraction

The section measures cognitive complexity before and after jump elimination and method extraction. The transformation can create a modest intermediate cost while enabling some previously unavailable extractions.

7.1 Experimental Design

  • The evaluation measured SSCC at three stages: original code, after jump removal, and after external method extraction, assessing each transformation alone and in combination.Source: §7.1 · p. 6, §7 · p. 6

7.2 Impact of the Transformation

  • The transformation’s SSCC increase remained below 11% in every evaluated project and was described as a controlled intermediate structural cost.It uses boolean state variables, modified loop conditions, and additional conditional blocks.Source: §7.2 · pp. 6–7

7.4 Synthesis

  • 10 of the 65 cases where extraction initially failed were recovered after transformation, approximately 15% of those cases.Recovered extractions achieved final SSCC below the external tool’s threshold of 15.Source: §7.3 · p. 7, §7.4 · p. 7

7.3 Results after Double Refactoring

  • The external extraction tool succeeded on the original code in seven cases but failed after the internal transformation, so the interaction was not uniformly beneficial.Source: §7.3 · p. 7

8 Discussion

The discussion emphasizes deterministic AST rewriting, the limits of immediate complexity scores, and the value of evaluating refactorings as a sequence of passes.

8.1 Deterministic AST Transformations vs. Non-Deterministic Tools

  • Eclipse AST manipulation provides deterministic rewrites that preserve execution paths, type bindings, and variable scopes, unlike approaches that may fail to ensure behavioral preservation in complex jump cases.The discussion contrasts this with observed LLM refactoring bugs and failures in non-linear jump scenarios such as nested finally blocks.Source: §8.1 · p. 7

8.2 Reinterpreting Maintainability and Metric Non-Linearity

  • Replacing jumps with boolean flags temporarily raises SSCC, but explicit conditional paths can facilitate later extraction and a net complexity reduction in some initially infeasible cases.The reported recovery was approximately 15% of cases where the external tool initially failed.Source: §8.2 · p. 7

8.3 Compositional Refactoring and Toolchain Evolution

  • The authors argue that removing non-local exit barriers lets standard IDE extraction tools process methods they previously rejected, making refactoring a compositional pipeline.They caution that structural changes can alter later tools’ search spaces and heuristics.Source: §8.3 · pp. 7–8

9 Conclusions and Limitations

The conclusion presents an Eclipse JDT plugin that replaces explicit loop jumps with boolean state variables, preserving behavior and preparing code for method extraction. It also identifies methodological conventions and evaluation boundaries.

9 Conclusions and Limitations

  • The plugin eliminates break and continue across Java loop types using boolean state variables, enabling subsequent automated method extraction.The conclusion describes the transformation as AST-driven and behavior-preserving.Source: §9 · p. 8

9.1 Main Technical Contributions

  • The production Eclipse JDT plugin performs deterministic, multi-pass AST rewrites and addresses control jumps that had blocked automated transformations.The paper also claims semantic integrity across nested loops and try-catch-finally scopes.Source: §9.1 · p. 8

9.2 Methodological Considerations

  • The transformation uses stay and keep as concise control-variable names and parenthesizes loop predicates when adding state flags.The parentheses prevent operator-precedence ambiguities in complex expressions.Source: §9.2 · p. 8

9.3 Threats to Validity and Limitations

  • The assessment did not measure architectural coupling or cohesion, nor runtime CPU or memory overhead from boolean-flag evaluations.The authors expect the overhead to be negligible.Source: §9.3 · p. 8
  • The magnitude of the Phase 2 SSCC reduction depends on the block-extraction heuristics in external IDE refactoring engines.This qualifies outcomes that rely on those engines' extraction behavior.Source: §9.3 · p. 8

10 Future Work

Future work proposes expanding the transformation's language and control-exit coverage, adding metrics feedback and search-based optimization, and adapting the pipeline for teaching.

10.1 Architectural and Language Extensions

  • Future extensions include support for labeled loop exits in deeply nested structures and portability to other object-oriented and imperative languages.The named targets include C#, C++, Python, and TypeScript.Source: §10.1 · p. 8

10.2 Metrics-Driven Optimization and Tool Integration

  • The plugin could compute SSCC directly to guide transformations using predicted post-extraction thresholds.The proposal gives dropping below standard thresholds as an example policy.Source: §10.2 · p. 8
  • Future integration could combine jump-elimination operators with heuristic-guided search and adapt the pipeline for interactive software-engineering education.The educational proposal would let students examine control-flow normalization and modular code evolution in real time.Source: §10.2 · p. 8
Loading 2609.27627v1…