StoneDetector: Java Clone Detection

• The paper introduces StoneDetector, a platform that uses dominator-tree paths to detect Type 1 through Type 4 code clones in Java.
• It employs control-flow analysis, path extraction, and configurable string metrics, such as modified LCS, to balance detection precision and performance.
• The system supports both Java source and bytecode inputs, achieving high precision and scalability on benchmarks like BigCloneBench while addressing challenging clone scenarios.

Searching arXiv for the specific StoneDetector paper and closely related clone-detection work for context. Searching arXiv for "StoneDetector conventional versatile code clone detection Java". StoneDetector is a code clone detection platform for Java that operates on both Java source code and Java bytecode. It implements a conventional clone detection approach, but its central representation is neither raw text nor tokens nor direct AST matching. Instead, it derives textual path descriptions from dominator trees, then compares those path sequences with configurable string metrics. This places StoneDetector between inexpensive text- or token-based detectors and more expensive graph-matching approaches, while explicitly targeting not only exact and near-miss clones but also harder Type 3 and some Type 4 cases (Heinze et al., 5 Aug 2025).

1. Definition, scope, and clone model

StoneDetector addresses code clone detection in Java projects, where duplicated and subsequently modified code can bloat systems and propagate bugs or vulnerabilities. The platform covers both Java source and Java bytecode, which is significant in settings where source is unavailable but deployable class files remain accessible. Its problem model follows the standard clone taxonomy: Type 1 clones are exact copies modulo layout, comments, or formatting; Type 2 clones additionally admit identifier renaming and literal changes; Type 3 clones allow inserted, altered, or deleted statements; and Type 4 clones are syntactically different but computationally similar (Heinze et al., 5 Aug 2025).

The system is explicitly designed to extend conventional clone detection further into larger-gap Type 3 and some Type 4 territory. A central premise is that many difficult clone pairs remain structurally related even when their surface syntax diverges substantially. The paper’s motivating examples include cases where continue is replaced by an else branch and try-finally is replaced by a different control-flow sequence with equivalent cleanup behavior. In such settings, raw text and token streams can diverge sharply, whereas dominator-tree paths may preserve the must-execute structural relations that remain shared (Heinze et al., 5 Aug 2025).

A common misconception is that StoneDetector is a semantic or neural clone detector. It is not presented that way. The platform is described as a conventional detector whose novelty lies in the choice of intermediate representation and in the breadth of its configurable comparison machinery. Another misconception is that it merely performs text comparison over normalized code. In fact, the compared strings are path encodings extracted from dominator trees, not from the original source layout (Heinze et al., 5 Aug 2025).

2. Dominator-tree representation and similarity model

StoneDetector begins from control flow graphs. A control flow graph is defined as $G=(N,E,s)$, where $N$ is the set of instruction nodes, $E$ the control-flow edges, and $s\in N$ the start node. The paper uses one node per instruction rather than basic blocks. A node $l$ dominates a node $k$ iff $l$ lies on all paths from $s$ to $k$, and immediate domination yields the dominator tree $D=(N,E^*)$ with

$N$0

Because the dominator tree is acyclic and every node has a unique path from the root, it can be linearized without the ambiguity of CFG comparison (Heinze et al., 5 Aug 2025).

The raw dominator tree is abstracted before comparison. Instructions are encoded in preorder-like textual form, and identifiers, field names, and literals are normalized aggressively: variables become $N$1, literals become $N$2, and related abstractions suppress superficial variation. The paper gives i = 0 becoming $N$3. Function calls may optionally preserve call-site names by a constant-pool-like encoding such as $N$4. This abstraction targets Type 2 variation directly and also reduces some Type 3 and Type 4 divergence (Heinze et al., 5 Aug 2025).

From each dominator tree, StoneDetector extracts all root-to-leaf paths. The resulting description set is the set of instruction sequences obtained by concatenating the abstract instructions along those paths. Similarity is then defined at two levels. At the path level, StoneDetector uses a distance function

$N$5

instantiated by configurable string metrics. At the description-set level, it aggregates best path matches through

$N$6

Two fragments are considered similar if

$N$7

with $N$8 normalized to the range $N$9 to $E$0 and a default of $E$1, informally corresponding to a 70% similarity threshold (Heinze et al., 5 Aug 2025).

The platform distinguishes “strictly similar” and “partially similar” fragments. Strict similarity requires equal description-set cardinality together with path-wise similarity, whereas partial similarity relaxes the cardinality condition and supports subclone cases. This is reinforced by the modified LCS metric, which introduces explicit large-gap and embedded-path acceptance rules. If code fragments consist of only one basic block or path, they are considered clones if the calculated LCS value corresponds to a value lower than 30% of the number of nodes of the smaller code fragment. A path $E$2 is considered a subpath of $E$3 if the calculated LCS value of $E$4 and $E$5 is less than 10% of the length of $E$6, and the smaller path must have minimum length 10 nodes (Heinze et al., 5 Aug 2025).

3. Metrics, hashing, and system architecture

StoneDetector is organized as a frontend/backend platform. The frontend transforms program artifacts into description sets or fingerprint sets; the backend performs clone matching. For Java source code, the pipeline is lexical and syntax analysis, AST generation, control-flow analysis, dominator-tree generation, path extraction, description-set encoding, optional fingerprint hashing, and clone matching with a configurable metric. For parsing, the platform uses Spoon, which supports Java up to version 20, and integrates WALA for dominator-tree construction because Spoon alone is insufficient for that stage. Dominator analysis is function-level. The tool can also run a standard interprocedural exception analysis for Java after Chang et al., and the paper reports that enabling exception analysis improves clone detection results (Heinze et al., 5 Aug 2025).

The comparison layer is unusually configurable. The paper lists LCS, modified LCS, Levenshtein, Needleman–Wunsch, Hamming, N-Gram, Jaccard, cosine, Jaro–Winkler, and Damerau–Levenshtein as available string metrics. The ablation study emphasizes modified LCS and Needleman–Wunsch as the best overall metrics, while Hamming is much faster but degrades markedly on more variant clones. For example, Hamming yields about a 3.5× speedup, but the paper recommends it mainly when Type 1 and Type 2 clones are the primary concern (Heinze et al., 5 Aug 2025).

Hashing is also configurable. StoneDetector can compare raw description sets directly or hashed fingerprint sets. It implements no hashing, a simple 4-byte prime-based hash, MD5, and LSH. MD5 is the default in the generic configuration table, but the best-performing evaluation setting uses modified LCS with LSH. The LSH variant operates at node level rather than only as candidate filtering: instructions are clustered by instruction length, with default clusters 3 through 8 and all longer instructions assigned to cluster 8; each cluster uses 200 buckets. The stated motivation is that syntactically very similar instructions, which would hash to unrelated MD5 values, can be mapped together under LSH and thereby improve recall for more variant clones without sacrificing precision in the reported experiments (Heinze et al., 5 Aug 2025).

Several runtime-oriented controls further define the platform. The main configuration table gives a minimum clone size $E$7 in lines of code, with default 15. The paper reports that increasing minimum clone size improves precision; across 6–20 LOC, recall stayed comparable while precision rose from about 96% up to 100%. Structural short-circuit filters skip comparisons when description-set sizes differ too much or path lengths differ too much; the best empirical tradeoff is a maximum description-set size factor of 1.7 and a maximum path-length difference of 7 nodes. StoneDetector also merges identical or near-identical paths within one description set; this does not affect recall or precision but improves runtime by about 20%, reducing a BigCloneBench run from about 25 to 20 minutes (Heinze et al., 5 Aug 2025).

4. Source and bytecode frontends

A distinctive feature of StoneDetector is that the same backend matcher supports both source and bytecode through separate frontends. The bytecode frontend uses Soot, which translates class files into Baf, a stack-based representation close to bytecode, or Jimple, a register-based three-address representation. StoneDetector then builds dominator trees over Baf or Jimple, extracts root-to-leaf paths, hashes them into fingerprints, and applies the same comparison backend. This frontend/backend separation is presented as an extensibility mechanism: any language or program representation can in principle be added by writing a frontend that produces fingerprints (Heinze et al., 5 Aug 2025).

The bytecode setting is not merely a direct transposition of the source-code pipeline. The paper reports heuristics that remove low-level instructions without source-level analogues, especially stack load/store operations in Baf, and heuristics that eliminate duplicate paths introduced by Baf or Jimple encodings of high-level control flow. These details matter because raw bytecode amplifies small source changes into larger low-level differences; the representation must therefore be normalized more aggressively to remain useful for clone detection (Heinze et al., 5 Aug 2025).

The empirical comparison between Baf and Jimple is decisive. On BigCloneBench-derived bytecode with minimum clone size 15 LOC, StoneDetector in the stack-based Baf frontend achieves Type 1 recall 99.9%, Type 2 recall 99.7%, VST3 97.2%, ST3 68.9%, MT3 10.9%, T4 0.0%, reports 439,767 clones, runs in 77.20 minutes, and attains 99% precision. With the register-based Jimple frontend, the system achieves Type 1 recall 99.9%, Type 2 recall 99.8%, VST3 99.7%, ST3 88.0%, MT3 16.8%, T4 0.0%, reports 600,522 clones, runs in 35.36 minutes, and again attains 99% precision. The thresholds differ, with $E$8 for Baf and $E$9 for Jimple. The paper’s conclusion is that Jimple is clearly the better bytecode representation for this method, both in recall and in runtime (Heinze et al., 5 Aug 2025).

This source/bytecode duality also clarifies what StoneDetector is not. It is not limited to source repositories, and it is not primarily a decompiler-dependent approach. Its core object of comparison is the dominator-path description set derived from whatever frontend representation is supplied (Heinze et al., 5 Aug 2025).

5. Evaluation, benchmark behavior, and scalability

The evaluation is extensive and uses several state-of-the-art benchmarks: BigCloneBench, GPTCloneBench, Google Code Jam 2022, and the Java subset of Project CodeNet. On BigCloneBench source code with minimum clone size 15 LOC, using the reported best configuration of 70% similarity threshold ($s\in N$0), modified LCS, and LSH, StoneDetector achieves the following results (Heinze et al., 5 Aug 2025).

Clone category	Recall	Context
Type 1	99.9%	20,828 detected
Type 2	99.9%	3,475 detected
Very-Strong Type 3	97.6%	3,209 detected
Strong Type 3	92.0%	6,808 detected
Moderate Type 3	23.6%	6,324 detected
Type 4	0.1%	6,061 detected

The same configuration reports 1,300,458 total clones with estimated precision of 99%. Precision is estimated manually because BigCloneBench provides only partial ground truth; the authors sample 400 clone pairs per detector, and three judges evaluate them blindly. This precision figure therefore reflects manual estimation rather than exhaustive verification (Heinze et al., 5 Aug 2025).

Relative to the compared conventional systems, StoneDetector’s strongest advantage is on the harder Type 3 categories while preserving high precision. On the same BigCloneBench source setup, NiCad reports ST3 84.3% and MT3 0.6% with 100% precision; SourcererCC reports ST3 78.1% and MT3 5.5% with 100% precision; CCAligner reports ST3 80.2% and MT3 6.6% with 98% precision; iClones reports ST3 88.2% and MT3 15.1% with 97% precision; NIL reports ST3 88.5% and MT3 13.1% with 99% precision; and Oreo reports ST3 88.9% and MT3 19.4% with 99% precision. Deckard reports many more apparent Type 4 clones, but at only 46% precision. StoneDetector is therefore not the best at Type 4 recall in absolute terms, but among the high-precision conventional tools it leads on Strongly Type 3 and Moderately Type 3 recall (Heinze et al., 5 Aug 2025).

Results on the alternative benchmarks are more nuanced. On GPTCloneBench, StoneDetector reports 4,068 clones and 23.9% recall, which is competitive but not best among the listed systems. On Google Code Jam, it reports 362,989 clones and 3.3% recall, ahead of NIL at 1.9%, Oreo at 1.1%, CCAligner at 0.9%, SourcererCC at 0.9%, and NiCad at 0.5%. On Project CodeNet, it reports 713,942 clones and 6.4% recall, ahead of NIL at 5.8%, Oreo at 4.8%, CCAligner at 1.4%, NiCad at 1.1%, and SourcererCC at 0.9%. These datasets contain many heterogeneously developed, semantically similar but syntactically diverse solutions, and all recalls are low; the paper interprets StoneDetector’s lead there as evidence that dominator-path comparison helps under larger syntactic variance (Heinze et al., 5 Aug 2025).

Scalability is another major result. On random subsets of IJaDataset 2.0, StoneDetector processes 1M LOC in 24 seconds, 10M LOC in 6.17 minutes, and 100M LOC in 7.13 hours. It is not the fastest system in every regime, but it scales to 100M+ LOC and remains competitive with large-scale tools. The paper further reports that it processed the full IJaDataset 2.0, about 328M LOC across roughly 2.5M Java files, in 79 hours (Heinze et al., 5 Aug 2025).

6. Limitations, interpretation, and significance

StoneDetector’s limitations are stated clearly by the evaluation. Despite the improved representation, true Type 4 detection remains weak in absolute terms, especially on BigCloneBench, where the reported Type 4 recall is 0.1%. The method therefore remains fundamentally structural and syntactic rather than semantic in an execution-based sense. A second limitation is parameter sensitivity: threshold choice, minimum clone size, metric selection, hashing strategy, and frontend representation all affect behavior, although the paper provides extensive tuning guidance and defaults (Heinze et al., 5 Aug 2025).

The validation methodology also imposes interpretive constraints. BigCloneBench is heavily dominated by Type 4 pairs and contains only partial ground truth, so precision must be estimated by manual sampling rather than exhaustive labeling. The authors therefore add GPTCloneBench, Google Code Jam, and Project CodeNet to reduce benchmark bias, but the paper still depends on benchmark design choices. Bytecode experiments introduce additional preprocessing assumptions: benchmark programs are made compilable using Stubber, reaching 95% of files, which the paper identifies as a threat to generality (Heinze et al., 5 Aug 2025).

These limitations matter for how StoneDetector should be situated within clone-detection research. It should not be read as a graph-matching method that has been simplified for engineering convenience, nor as a neural method disguised as a conventional detector. Its main contribution is more specific: it demonstrates that dominator trees can serve as an intermediate representation from which root-to-leaf path sets preserve enough control-flow semantics to enlarge the reach of conventional sequence-comparison clone detection while retaining practical scalability. This suggests that, in clone detection, representational choice can be as consequential as the matching algorithm itself (Heinze et al., 5 Aug 2025).

A final misconception concerns versatility. The platform is versatile in the sense reported by the paper: multiple metrics, multiple hashes, source and bytecode frontends, optional exception analysis, configurable thresholds, and large-scale execution. That versatility does not imply universality. The reported evidence is for Java source and Java bytecode, and the broader applicability to other languages is presented as an extensibility property of the architecture rather than as an experimentally validated result (Heinze et al., 5 Aug 2025).