JC-Finder: Java Class-Level Clone Detection

• The paper presents JC-Finder, a clone-based SCA tool that pioneers class-level analysis to accurately detect copy-and-paste reuse of third-party libraries in Java.
• JC-Finder extracts Linked Function ASTs and builds Class ASTs to preserve inter-method relationships while filtering trivial, duplicated, or design-pattern code for robust TPL detection.
• Empirical evaluations show JC-Finder achieves a 0.818 F1-score and is approximately 9 times faster than CENTRIS4J, highlighting its significant impact on software maintenance and security.

Searching arXiv for the specified paper and closely related work to ground the article. JC-Finder is a clone-based Software Composition Analysis (SCA) tool designed specifically for Java, with a new focus on class-level analysis rather than files or individual functions. It targets third-party libraries (TPLs) that are reused via copy-and-paste of source code instead of through package managers like Maven, and it seeks to identify such reuse accurately and comprehensively by capturing features at the class level, maintaining inter-function relationships, and excluding trivial or duplicated elements (Zhao et al., 4 Aug 2025).

1. Problem setting and rationale

JC-Finder is situated within the broader distinction between package-manager-based SCA and clone-based SCA. PM-based SCA parses build manifests such as pom.xml and dependency trees to list declared libraries and their versions, whereas clone-based SCA detects libraries by analyzing source or binary similarity. The tool addresses the specific case in which Java projects reuse TPLs by source-code cloning rather than by package-manager declaration. The paper frames this as a maintenance, security, and ethics problem: undeclared reuse weakens version management, complicates SBOM construction and vulnerability scanning, and may raise license-violation or plagiarism concerns (Zhao et al., 4 Aug 2025).

The rationale for a Java-specific design follows from two limitations of prior clone-based approaches. File-level detection is too coarse for Java because a single .java file may contain multiple classes, and only part of that file may be reused. The paper reports that 10.38% of Java files contain more than one class and illustrates the issue with AnimatedGifEncoder.java, where only LZWEncoder is reused elsewhere. Function-level detection is too fine-grained: it treats methods as independent units even though Java classes encapsulate interacting methods, shared state, inheritance, and polymorphism. It is also vulnerable to large volumes of boilerplate functions such as getters, setters, and simple initializers, which can produce false positives (Zhao et al., 4 Aug 2025).

The paper gives an empirical example of this noise problem. Using TACC for function-level clones on 1,000 Java projects, 56.4% of functions had clones. In the case of edal-java and org.infinispan:infinispan-embedded, 39.1% of functions in edal-java had clones in the library even though the projects were unrelated; most matches were trivial boilerplate. This motivates the shift from file-level and function-level representations to the class as the primary unit of clone-based TPL recognition (Zhao et al., 4 Aug 2025).

2. Empirical basis for class-level detection

A central premise of JC-Finder is that Java clone reuse often preserves class-level functional structure rather than isolated methods. The paper studies this through two notions: associated clones and conjugate clones. Associated clones refer to caller–callee behavior within a class: for each method, the analysis checks how many of its callees are also cloned alongside it. The reported associated clone percentage shows that 80% of callers had more than 50% of their callees cloned, and 76% had 100% associated clone percentage. This indicates that when one method is cloned, its intra-class dependencies are often cloned with it as well (Zhao et al., 4 Aug 2025).

Conjugate clones measure whether two classes share multiple one-to-one cloned methods. For classes $A$ and $B$, with $n$ and $m$ methods respectively, and clone-pair set $C_{A,B}$, the paper defines the conjugate clone percentage as

$$P = \frac{\left| \{(a_i, b_j), (a_k, b_l) \in C_{A,B} \mid i \neq k \wedge j \neq l \} \right| \times 2}{n + m}.$$

This quantity measures how many methods in both classes participate in distinct clone pairs. The reported results show that about 81% of classes had conjugate clone percentage greater than 50%, and 48% had 100% conjugate clone percentage. The paper interprets this as evidence that Java functions are often cloned in groups that reflect class-level reuse rather than as unrelated fragments (Zhao et al., 4 Aug 2025).

These observations are the empirical basis for JC-Finder’s class-level tree analysis. They suggest that a representation preserving intra-class call structure should better capture clone-based TPL reuse than either whole-file hashing or thresholded sets of function clones.

3. Architecture and class-level tree analysis

JC-Finder has a three-stage pipeline: Feature Extracting, Feature Refining, and TPL Recognition. In Feature Extracting, each Java file is partitioned into class declarations using JavaParser. Each method in a class is parsed into a Function AST and normalized by replacing variable and method names with generic labels such as "Simple Name" and replacing literal values with generic types such as "Primitive Type" and "Literal". The paper states that this skeletonization is inspired by Sager et al. and is intended to make the representation robust against Type-1 and Type-2 changes, and many Type-3 changes (Zhao et al., 4 Aug 2025).

The representation is then extended from isolated functions to linked functions. For each method, JC-Finder traverses its AST, detects invocations of other methods defined in the same class, and replaces the call node with the callee’s AST body recursively. External calls are replaced with a "Dummy External Node". Direct self-recursion is represented by a "Dummy Recursive Node" to prevent infinite expansion. Cycles of internal calls are broken heuristically: if two methods call one another, only the call from the “larger” function to the “smaller” is preserved, where “larger” is determined by higher lines of code and more outgoing calls. The resulting structure is called a Linked Function AST (Zhao et al., 4 Aug 2025).

A Class AST is then built by creating a new root node for the class and attaching each Linked Function AST as a child. This turns the class into a single structural object that preserves both the existence of methods and the internal call relationships among them. The paper treats the resulting Class AST as the canonical feature-bearing unit for TPL detection (Zhao et al., 4 Aug 2025).

Comparison is performed through order-insensitive hashing. The paper describes a bottom-up procedure in which each leaf receives a base hash and each parent combines its own hash with the hashes of all child nodes. Because the aggregation is order-insensitive, reordering methods within a class or independent subtrees within a method does not change the resulting root hash. The root hash becomes the class feature. A plausible implication is that this design makes JC-Finder particularly suited to class-level Type-1, Type-2, and some Type-3 clone detection while remaining computationally compact (Zhao et al., 4 Aug 2025).

4. Feature refinement and originality resolution

The second stage, Feature Refining, removes classes that are likely to be noisy, trivial, duplicated, or structurally uninformative. The first refinement step filters supporting classes through four criteria. It removes interfaces without concrete implementations and empty classes; filters trivial functions using the Maintainability Index formula

$$MI = 171 - 5.2 \times HV - 0.23 \times CC - 16.2 \times LOC;$$

defines function complexity as

$$\text{Complexity} = 5.2 \times HV + 0.23 \times CC + 16.2 \times LOC;$$

and treats functions with complexity less than 60 as trivial. Classes that consist only of such methods are discarded. The same stage also filters structural design-pattern classes by naming patterns such as *Factory, *Adapter, and *Converter, and removes test classes whose paths or names contain “test” as prefix or suffix (Zhao et al., 4 Aug 2025).

The second refinement step filters classes by centrality. For each library, JC-Finder builds a class dependency graph whose nodes are classes and whose edges represent uses or dependencies among classes. It then computes PageRank over that graph and converts the scores to percentiles. To choose a cutoff, the authors sampled 385 clone-pairs that were manually validated as true TPL reuses and found that 95.63% of reused classes lie within the top 50% of PageRank. JC-Finder therefore discards classes in the bottom 50% percentile, retaining only classes that are central within the library’s dependency structure (Zhao et al., 4 Aug 2025).

The third refinement step resolves duplicated classes and library originality. Within each Maven groupId, identical class hashes are merged into one feature record and associated with the list of (artifact, version) pairs that contain that class; the timestamp of the earliest artifact release is retained. Across different groups, identical hashes are compared by timestamp, and the earliest feature is kept as the original while later duplicates are discarded. The paper presents this as a way to avoid attributing the same cloned class to multiple downstream libraries and to reduce false positives caused by repackaging or code migration across artifacts (Zhao et al., 4 Aug 2025).

5. Evaluation and reported performance

The reference dataset used to build the library fingerprint database consists of 9,965 most popular Maven libraries and 543,286 versions. Only source JARs were analyzed. For project-side evaluation, the study assembled a GitHub dataset of Java repositories that successfully built with mvn compile; from this corpus, 1,000 projects were randomly sampled for manual ground-truth construction. Two experts labeled 68 projects with 167 TPL reuse instances over two months, using path and package names, change logs, copyright and license information, and author affiliation as evidence (Zhao et al., 4 Aug 2025).

The main baseline was CENTRIS4J, a Java adaptation of the function-level CENTRIS pipeline. Threshold tuning over 5% to 25% showed that 15% gave the highest F1-score for the baseline, and that configuration was used in comparison. On the 1,000-project ground-truth set, JC-Finder achieved precision 0.698, recall 0.986, and F1-score 0.818, whereas CENTRIS4J achieved precision 0.270, recall 0.706, and F1-score 0.391. The reported F1 improvement is 0.427 (Zhao et al., 4 Aug 2025).

The efficiency results are similarly pronounced. Generating the reference feature database over the 543,286 library versions took 52 hours for JC-Finder and 216 hours for CENTRIS4J. For TPL recognition on the 1,000-project evaluation set, JC-Finder took 14.2 seconds on average, with variance 2.87, whereas CENTRIS4J took 126.6 seconds on average, with variance 39.39. The abstract summarizes this as approximately 9 times faster than the function-level tool (Zhao et al., 4 Aug 2025).

The paper also defines two measures for large-scale SCA enhancement. Let $TPL_{PM}$ be the set of TPLs declared through package managers and $TPL_{CC}$ the set detected through code clones. The Improvement Rate is

$B$0

with $B$1 set to 1 when $B$2 but $B$3. The Duplication Rate is

$B$4

These metrics are used to quantify how much clone-based recognition adds beyond PM-based SCA (Zhao et al., 4 Aug 2025).

6. Reported impact, complementarity, and limitations

In the large-scale GitHub study, JC-Finder reported TPL reuse by code clones in 789 projects, or about 9.89% of all projects, and identified a total of 2,142 TPLs. The average Improvement Rate over those projects was 26.20%, while the average Duplication Rate was 1.08%. The paper interprets this as evidence that clone-based SCA is largely complementary to PM-based SCA rather than redundant with it. Pearson correlation between the number of clone-detected TPLs and project star count was 0.065, and the correlation with project size was 0.232, indicating only weak dependence on popularity or repository scale (Zhao et al., 4 Aug 2025).

The article’s broader significance lies in the way it redefines the granularity of clone-based SCA for Java. JC-Finder treats the class, rather than the file or the function, as the primary semantic unit of reuse. This allows it to preserve inter-method structure through Linked Function ASTs, suppress noise through triviality and centrality filtering, and avoid repeated attribution through timestamp-based originality resolution. A plausible implication is that the tool is especially well aligned with Java’s object-oriented organization, where copied functionality often survives as a coherent class or subsystem rather than as isolated functions (Zhao et al., 4 Aug 2025).

The paper also identifies several limitations. Detection quality depends on the completeness of the reference dataset, and 158,316 library versions lacked source JARs, which can distort originality resolution. Web-only or non-Maven libraries cannot be mapped cleanly even when their code is clearly cloned. Auto-generated code from tools such as JavaCC or Thrift may appear in many projects and libraries, creating attribution ambiguity. The ground truth is deliberately conservative and prioritizes soundness over completeness. Finally, the complexity threshold of 60 and the naming-based design-pattern filters remain heuristic, even though they are empirically justified in the study (Zhao et al., 4 Aug 2025).

Within Java SCA, JC-Finder therefore occupies a specific role: it is not a replacement for PM-based dependency analysis, but a clone-based complement aimed at uncovering undeclared TPL reuse that conventional manifest-driven tools cannot observe.