Pith. sign in

REVIEW 5 major objections 6 minor 87 references

JC-Finder: Detecting Java Clone-based Third-Party Library by Class-level Tree Analysis

T0 review · 5 major / 6 minor · reviewed 2026-08-06 · deepseek-v4-flash

Pith's one-line read JC-Finder claims that clone-based third-party library reuse in Java is best detected at class level, representing each class as an order-insensitive tree of interlinked function ASTs, and that this representation plus aggressive feature…

desk verdict A genuinely new Java SCA tool with a valuable dataset, but the headline F1 is partly calibrated on the evaluation ground truth, so treat the numbers with caution. read the letter →

arxiv 2508.02397 v1 pith:OYUDNG7Q submitted 2025-08-04 cs.SE

classification cs.SE
keywords codeclonedetectionsoftwarecompositionanalysisthird-partylibraryreuseJavaclass-levelgranularityabstractsyntaxtreePageRankcentralityMaven
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

The paper tries to establish that third-party library (TPL) reuse introduced by copy-and-paste in Java is better detected at the granularity of classes than of files or individual functions. It argues that Java's object-oriented structure makes the class the natural unit of reuse: functions inside a class tend to be copied together, so preserving their caller-callee and co-existence relations matters. To use this insight, JC-Finder builds a 'Class AST' from linked function ASTs and filters away supporting, trivial, low-centrality, and duplicated classes before matching against a reference set of 9,965 Maven libraries. The authors report that this approach reaches recall 0.986 and precision 0.698, roughly nine times faster than a Java-adapted version of the function-level tool CENTRIS, and that it identifies 26.20% more TPLs than package-manager-based scanning alone. If correct, the result means Java can have clone-aware software composition analysis at scale, and package-manager-only SBOMs systematically undercount real reuse.

What carries the argument

The Class AST with Linked Function ASTs is the central object: each function is parsed into an AST whose identifier names and values are replaced by type placeholders, then internal function invocations are expanded inline, external calls become Dummy External Nodes, recursion becomes a Dummy Recursive Node, and the resulting function trees are attached under a class root with an order-insensitive hash so rearranged code still matches. This carries the argument because it treats the class as the unit of reuse, preserves intra-class relationships, and tolerates Type 1, 2, and 3 clones. The supporting machinery is the three-stage feature refiner: supporting-class rules (C1 through C4), a PageRank centrality cutoff at the 50th percentile, and timestamp-based deduplication of classes shared across libraries.

What would settle it

Build an independent ground truth of clone-based TPL reuse for a fresh set of Java projects, using license headers, 'forked from' comments, and change logs, then check how many confirmed reused classes fall into the bottom 50% of their library's PageRank distribution. If that fraction is close to the paper's observed 4.37%, the reported recall of 0.986 should reproduce; if it is substantially larger, the centrality filter is discarding real evidence and the reported recall will not hold up.

Watch

Extended reading notes

Core claim

The central discovery is that class-level granularity with inter-function relationships solves the accuracy problem of clone-based SCA for Java while also saving computation. The paper shows empirically from 1,000 GitHub projects that functions in the same class are usually cloned together: 76% of caller functions have all their callees cloned alongside them, and 48% of classes are fully cloned in conjugate pairs. This motivates representing a class as a Class AST whose function subtrees are linked along internal invocation edges, with external calls replaced by dummy nodes and recursion broken deterministically. Feature refinement then removes interface and empty classes, trivial functions below a complexity score of 60, structural design-pattern classes, test classes, classes in the bottom 50% of the library's PageRank centrality distribution, and duplicate classes resolved by earliest Maven release timestamp. Matching a project class against this refined library feature set yields the reported 0.986 recall, 0.698 precision, and 0.818 F1-score on a manually labelled ground truth of 1,000 projects.

Load-bearing premise

The most fragile premise is that classes representing true library reuse almost always fall in the top half of their library's PageRank centrality distribution, so discarding the bottom half loses at most a few percent of recall; this cutoff was chosen from 385 manually confirmed clone pairs in the same ground truth later used to measure accuracy.

Editorial extensions

If this is right

  • If JC-Finder's reported accuracy holds, Java SCA tools can safely include clone-introduced TPLs in their SBOMs, catching reuse that package-manager scans miss.
  • The 26.20% improvement rate suggests that roughly one in four clone-detected TPLs in the studied 7,947 projects would be invisible to PM-based scans.
  • Because the method replaces threshold-based matching with exact class-feature matching, it removes the need to tune a similarity threshold per project or per library.
  • Class-level features generated once for 543,286 library versions can be reused for scanning arbitrary future projects, making the approach practical for continuous integration.

Reading between the lines

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

  • A direct testable extension is to vary the PageRank cutoff and re-measure precision and recall; if precision is insensitive across a range of cutoffs, the 50% threshold is robust, otherwise it is overfit to the ground truth.
  • The timestamp-based origin rule implies that reuse whose original release predates Maven source JAR availability will be systematically misattributed; adding provenance signals such as commit history or package naming could reduce that error.
  • If JC-Finder were integrated into vulnerability scanning, the 26.20% extra TPLs implies current SBOM-driven vulnerability databases may miss a comparable fraction of clone-based exposures.
  • The class-level linked-AST representation could generalize to other object-oriented languages, but the paper only evaluates Java, so any cross-language claim remains an extension rather than a result.
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.

Referee Report

5 major / 6 minor

Summary. This manuscript presents JC-Finder, a clone-based Software Composition Analysis tool for Java that operates at class granularity. Classes are represented as 'Class ASTs' built from normalized function ASTs, with intra-class call relations expanded and external calls replaced by placeholders. The reference index is constructed from 9,965 Maven libraries (543,286 versions) and refined by removing supporting classes, low-PageRank classes, and duplicate classes resolved by earliest release timestamp. TPL reuse is decided by matching test-project class features against the refined index. The evaluation on 1,000 GitHub projects reports precision 0.698, recall 0.986, F1 0.818, and an average resolution time of 14.2 seconds per project, compared with a Java-adapted CENTRIS baseline (CENTRIS4J). A further study of 7,947 projects reports that 789 projects reuse TPLs by cloning and that JC-Finder finds 26.20% more TPLs than package-manager declarations.

Significance. If the reported results were obtained under a sound evaluation protocol, the paper would make a useful contribution: it is the first Java-specific clone-based SCA tool at class granularity, it provides a manually labeled ground-truth set, and the tool and data are released. The efficiency gain (52 h vs 220 h for feature generation; 14.2 s vs 126.6 s per project) is substantial, and the 26.20% additional TPL finding gives concrete evidence that clone-based SCA complements package-manager detection. However, the headline accuracy is currently undermined because key thresholds are selected on the same ground truth later used for the final evaluation, so the reported precision, recall, and F1 are partly fitted to the test labels rather than being independent estimates.

major comments (5)
  1. [§4.2.2, §5.1.2, §5.2] The 50% PageRank cutoff is chosen after inspecting 385 clone pairs that were confirmed using the same ground-truth labeling procedure and the same 1,000-project dataset later used to compute Table 1. Because this cutoff discards all class features in the bottom half of the centrality distribution, the reported recall of 0.986 and F1 of 0.818 are partly fitted to the evaluation labels. The fact that 95.63% of the 385 pairs fall in the top 50% does not establish generalization beyond that sample. Please re-run the calibration on a held-out portion of the ground truth, or use nested cross-validation, and report metrics with and without the PageRank filter on the held-out set.
  2. [§4.2.1, §6.1] The trivial-function complexity threshold of 60 is a free parameter set by inspecting 400 functions and by the authors' agreement, which the manuscript itself flags as expertise-dependent in Section 6.1. Since this threshold determines which functions survive into class features, it affects all downstream matching and thus the central claim. Please provide a sensitivity analysis over the complexity threshold and validate the chosen value on data not used to set it.
  3. [§4.2.3, Figure 6, §5.2] The timestamp rule for deduplicating cloned classes assumes the earliest released source JAR is the origin of a class, but 158,316 of the 543,286 collected versions lack source JARs, and Figure 6 shows that missing source JARs can flip the attribution and create both false positives and false negatives. The manuscript acknowledges this limitation but does not quantify its effect on the reported precision and recall. Please report how many duplicated features are affected by missing-source-JAR ambiguity and run a sensitivity analysis in which ambiguous features are excluded or handled conservatively.
  4. [§5.2, Table 1] The comparative evaluation is not conducted under an independent calibration protocol: JC-Finder's PageRank cutoff is tuned on the same 1,000-project ground truth, and CENTRIS4J's 15% threshold is also described as offering optimal F1 on that same ground truth. Even if the baseline tuning is favorable to CENTRIS4J, the magnitude of the reported advantage is uncertain. Please separate calibration from test, for example by splitting the labeled projects into calibration and test sets or by evaluating on an independent labeled sample, and report the comparison on the test portion only.
  5. [§5.1.2, §6.1] The ground truth is deliberately described as 'sound but not complete', and only 68 of the 1,000 projects are confirmed positive. Under an incomplete ground truth, unlabeled true reuses can be counted as false positives, which would understate precision, while recall is computed only against the known positives. Please report how ambiguous or unlabeled cases were handled in the metric computation, the number of such cases, and a sensitivity analysis on the completeness assumption.
minor comments (6)
  1. [Section 1 and Section 5.2 (Answering RQ1)] The reported differences over CENTRIS4J are inconsistent: Table 1 implies precision, recall, and F1 differences of 0.428, 0.280, and 0.427, whereas the Introduction reports 0.462 and 0.353 and the RQ1 answer reports 0.462, 0.353, and 0.475. Please reconcile these numbers.
  2. [§5.1.1, §5.4, Abstract] Section 5.1.1 reports 7,974 remaining projects, while RQ3 and the abstract use 7,947. Please correct the typo and ensure all project counts are consistent.
  3. [§4.2.3] The deduplication rule is described as first merging features within groups and then removing duplicates between groups, but the exact decision rule for cases where the earliest timestamps are equal or where the same feature appears in many groups is not stated. Please give a formal rule or a small worked example.
  4. [§3.3.1] In the conjugate clone percentage formula, the symbol C_{A,B} is used for both the set of clone pairs and its cardinality, and the set-builder notation in the displayed equation is missing the existential condition. Please disambiguate the notation.
  5. [Figure 7] The axes of Figure 7 are not labeled with units, so it is unclear what 'project size' means and how scan time is measured. Please add axis labels and units.
  6. [§5.2] The threshold grid for CENTRIS4J is described only as 'from 5% to 25%'; please state the step size and the exact F1 values at each threshold for transparency.

Circularity Check

1 steps flagged · score 6.0 of 10

The PageRank pruning cutoff is calibrated on the same ground truth later used for RQ1 metrics, so the reported recall 0.986 and F1 0.818 are partly fitted rather than predicted.

  1. fitted input called prediction [Section 4.2.2 (Filter Classes By Centrality), evaluated in Section 5.2 (RQ1) against Section 5.1.2 ground truth]
    "Among all the classes that are confirmed to indicate TPL reuse, we picked 385 pairs of cloned classes to observe the distribution of their percentiles... From the results shown in Figure 5, 95.63% of classes are within the top 50% percentiles. Therefore, we remove the classes within the bottom 50% percentiles, as they are statistically considered to be supporting classes that are not representative enough to indicate TPL reuse effectively."

    The centrality cutoff is the paper's load-bearing feature-pruning rule, and it is set from the 385 clone pairs that were confirmed to indicate TPL reuse while building the ground truth described in Section 5.1.2. The same ground-truth labels are then used in Section 5.2 to compute JC-Finder's precision 0.698, recall 0.986, and F1 0.818. Thus the filter is not an independent design choice: it is calibrated so that 95.63% of the labeled positives survive, and the headline effectiveness numbers are measured on the very labels used for that calibration. No held-out set, cross-validation, or sensitivity analysis around the 50% cutoff is reported, so the recall improvement over CENTRIS4J is partly a fitted artifact rather than a prediction.

full rationale

JC-Finder's central technical mechanism, class-level Linked Function ASTs with order-insensitive hashing and inter-function invocation linking, is an engineering design rather than a formal derivation, so most of the paper is not circular in the mathematical sense. The comparison against CENTRIS4J is an external baseline, and the RQ3 deployment finding of 26.20% additional TPLs is an observational result, not an input-derived equivalence. The one significant circularity is the calibration of the PageRank centrality filter: the 50% cutoff is chosen after examining 385 clone pairs from the same ground truth that later defines the RQ1 labels, and the reported recall and F1 are computed on those same projects. This is a fitted-input-called-prediction pattern: a critical hyperparameter is tuned on the test set, making the absolute accuracy metrics partially self-fulfilling. The trivial-function threshold of complexity below 60 is set from a separate 400-function sample and is acknowledged in the threats section as expert-dependent; it is a weaker calibration concern but not label-fitting. No load-bearing self-citation chain or uniqueness-import issue is present: Sager et al. and CENTRIS are external, and TACC is used as a measurement tool rather than as proof. Overall the paper has substantial independent content, but the headline effectiveness numbers are partially reduced to the ground-truth calibration, so the score is 6 rather than 0-2.

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

The central claim rests on two empirically calibrated thresholds (complexity<60 and bottom-50% PageRank cutoff), a sampling-based assumption that functions are copied together with their class, and a timestamp-based originality assumption. None of these are independently verified outside the paper's own data, and one is calibrated on the evaluation ground truth. No invented entities are introduced.

free parameters (3)
  • trivial function complexity threshold = 60
    In Section 4.2.1 C2, after manually inspecting 400 functions, all functions with computed complexity lower than 60 were treated as trivial and removed from class features; this threshold directly shapes the feature set used for matching.
  • PageRank percentile cutoff = bottom 50% removed
    In Section 4.2.2, 385 ground-truth clone pairs showed 95.63% of reused classes in the top 50 percentiles; the bottom 50% are removed. This threshold is calibrated on the same ground truth that later evaluates the tool.
  • CENTRIS4J matching threshold = 15%
    In Section 5.2, the baseline threshold was tuned from 5% to 25% on the 1,000-project ground truth and 15% chosen for best F1; it affects the fairness and magnitude of the comparison.
assumptions (5)
  • domain assumption Functions in the same Java class tend to be copied together, so class-level matching preserves TPL reuse evidence.
    Section 3.3.1 reports that 80% of callers have associated clone percentage above 50% and 81% of classes have conjugate clone percentage above 50%, based on TACC with a 0.7 similarity threshold. This empirical tendency motivates class-level granularity but is not a proven universal property.
  • domain assumption Maven source JAR release timestamps identify the original version of a duplicated class.
    Section 4.2.3 keeps the class with the earliest timestamp as original; Section 6.1 and Figure 6 acknowledge that missing source JARs make this assumption fail and cause false positives and false negatives.
  • ad hoc to paper Maintainability Index complexity below 60 identifies trivial functions that should be removed.
    Section 4.2.1 C2 sets this cutoff from 400 inspected functions; Section 6.1 concedes that different experts might set a different threshold.
  • ad hoc to paper PageRank percentile in the class dependency graph measures a class's representativeness for TPL reuse, so the bottom 50% can be discarded.
    Section 4.2.2 justifies the cutoff using 385 ground-truth clone pairs from the evaluation dataset; there is no independent validation of this mapping.
  • domain assumption JavaParser 3.25.5 parses the Java constructs present in the corpus.
    Section 3.2 notes JavaParser has limitations with newer Java features and some files fail to parse, so unparseable classes are silently absent from the feature set.

how reviews work

0 comments
Cite this review

Pith. "Pith review of JC-Finder: Detecting Java Clone-based Third-Party Library by Class-level Tree Analysis." pith.science (2026). https://pith.science/paper/OYUDNG7Q

@misc{pith2026250802397,
  author       = {Pith},
  title        = {Pith review of: JC-Finder: Detecting Java Clone-based Third-Party Library by Class-level Tree Analysis},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/OYUDNG7Q}},
  note         = {Machine review of arXiv:2508.02397}
}
read the original abstract

While reusing third-party libraries (TPL) facilitates software development, its chaotic management has brought great threats to software maintenance and the unauthorized use of source code also raises ethical problems such as misconduct on copyrighted code. To identify TPL reuse in projects, Software Composition Analysis (SCA) is employed, and two categories of SCA techniques are used based on how TPLs are introduced: clone-based SCA and package-manager-based SCA (PM-based SCA). Although introducing TPLs by clones is prevalent in Java, no clone-based SCA tools are specially designed for Java. Also, directly applying clone-based SCA techniques from other tools is problematic. To fill this gap, we introduce JC-Finder, a novel clone-based SCA tool that aims to accurately and comprehensively identify instances of TPL reuse introduced by source code clones in Java projects. JC-Finder achieves both accuracy and efficiency in identifying TPL reuse from code cloning by capturing features at the class level, maintaining inter-function relationships, and excluding trivial or duplicated elements. To evaluate the efficiency of JC-Finder, we applied it to 9,965 most popular Maven libraries as reference data and tested the TPL reuse of 1,000 GitHub projects. The result shows that JC-Finder achieved an F1-score of 0.818, outperforming the other function-level tool by 0.427. The average time taken for resolving TPL reuse is 14.2 seconds, which is approximately 9 times faster than the other tool. We further applied JC-Finder to 7,947 GitHub projects, revealing TPL reuse by code clones in 789 projects (about 9.89% of all projects) and identifying a total of 2,142 TPLs. JC-Finder successfully detects 26.20% more TPLs that are not explicitly declared in package managers.

Figures

Figures reproduced from arXiv: 2508.02397 by the authors.

Figure 1
Figure 1. Associated Clone Percentage Distribution [PITH_FULL_IMAGE:figures/full_fig_p006_1.png] view at source ↗
Figure 3
Figure 3. Conjugate Clone Pairs The analysis of associated clones confirmed that most callers are cloned alongside their callees within a class. Still, some functions can be cloned together even without a direct caller-callee relation. We introduced conjugate clone pairs and conducted more experiments to dive deeper. Conjugate clone pairs are clone pairs that occur between two classes, where multiple pairs of identical or sim… view at source ↗
Figure 4
Figure 4. Overview of JC-Finder under the same classes) invocations are linked and external function (functions declared in other classes) invocations are not linked. To achieve this, we locate and replace the function invocations with its function body recursively until all internal function invocations have been replaced. For external function invocations, we replace them with a placeholder node called “Dummy External Node”… view at source ↗
Figures from the paper (3 more)
Figure 5
Figure 5. Figure 5: Percentile Distribution of Reused Classes [PITH_FULL_IMAGE:figures/full_fig_p011_5.png]
Figure 6
Figure 6. Figure 6: Clone Timeline Example [PITH_FULL_IMAGE:figures/full_fig_p015_6.png]
Figure 7
Figure 7. Figure 7: Time Comparison of TPL Recognition Results [PITH_FULL_IMAGE:figures/full_fig_p016_7.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

87 extracted references · 78 canonical work pages

  1. [1]

    DéjàVu: a map of code duplicates on GitHub

    2017. DéjàVu: a map of code duplicates on GitHub. Proceedings of the ACM on Programming Languages 1 (10 2017), 28. Issue OOPSLA. https://doi.org/10.1145/3133908

  2. [2]

    OWASP Dependency-Check Project - OWASP

    2021. OWASP Dependency-Check Project - OWASP. https://owasp.org/www-project-dependency-check/

  3. [3]

    Eclipse Steady

    2022. Eclipse Steady. https://github.com/eclipse/steady

  4. [4]

    Sonatype OSS Index

    2022. Sonatype OSS Index. https://ossindex.sonatype.org/

  5. [5]

    About alerts for vulnerable dependencies - GitHub Docs

    2023. About alerts for vulnerable dependencies - GitHub Docs. https://docs.github.com/en/code-security/supply- chain-security/managing-vulnerabilities-in-your-projects-dependencies/about-alerts-for-vulnerable-dependencies

  6. [6]

    Apache License, Version 2.0

    2023. Apache License, Version 2.0. https://opensource.org/license/apache-2-0/

  7. [7]

    Apache Thrift

    2023. Apache Thrift. https://thrift.apache.org/

  8. [8]

    Base64: Public Domain Base64 Encoder/Decoder

    2023. Base64: Public Domain Base64 Encoder/Decoder. https://iharder.sourceforge.net/current/java/base64/

Show all 87 references
  1. [9]

    Code metrics - Maintainability index range and meaning - Visual Studio (Windows) | Microsoft Learn

    2023. Code metrics - Maintainability index range and meaning - Visual Studio (Windows) | Microsoft Learn. https://learn.microsoft.com/en-us/visualstudio/code-quality/code-metrics-maintainability-index-range-and- meaning?view=vs-2022

  2. [10]

    CycloneDX - External Referneces

    2023. CycloneDX - External Referneces. https://cyclonedx.org/use-cases/#external-references

  3. [11]

    Dive into Design Pattern

    2023. Dive into Design Pattern. https://refactoring.guru/design-patterns

  4. [12]

    Dive into Design Pattern - Abstract Factory

    2023. Dive into Design Pattern - Abstract Factory. https://refactoring.guru/design-patterns/abstract-factory

  5. [13]

    Dive into Design Pattern - Adaptor

    2023. Dive into Design Pattern - Adaptor. https://refactoring.guru/design-patterns/adapter

  6. [14]

    eclipse IDE for Java Developers

    2023. eclipse IDE for Java Developers. https://www.eclipse.org/downloads/packages/release/kepler/sr1/eclipse-ide- java-developers

  7. [15]

    Gradle Build Tool

    2023. Gradle Build Tool. https://gradle.org/

  8. [16]

    JavaCC - The most popular parser generator for use with Java applications

    2023. JavaCC - The most popular parser generator for use with Java applications. https://javacc.github.io/javacc/

  9. [17]

    JavaParser

    2023. JavaParser. http://javaparser.org/

  10. [18]

    lib filter - An HTML filtering library

    2023. lib filter - An HTML filtering library. https://www.source-code.biz/

  11. [19]

    Libraries.io - The Open Source Discovery Service

    2023. Libraries.io - The Open Source Discovery Service. libraries.io

  12. [20]

    Maven Repository: Search/Browse/Explore

    2023. Maven Repository: Search/Browse/Explore. https://mvnrepository.com/

  13. [21]

    Maven Repository:org.apache.opennlp opennlp-tools

    2023. Maven Repository:org.apache.opennlp opennlp-tools. https://mvnrepository.com/artifact/org.apache.opennlp/ opennlp-tools

  14. [22]

    Maven – Introduction

    2023. Maven – Introduction. https://maven.apache.org/what-is-maven.html

  15. [23]

    Pearson correlation coefficient - Wiki

    2023. Pearson correlation coefficient - Wiki. https://en.wikipedia.org/wiki/Pearson_correlation_coefficient

  16. [24]

    Porter Stemming Algorithm

    2023. Porter Stemming Algorithm. https://tartarus.org/martin/PorterStemmer/

  17. [25]

    Reading-eScience-Centre/edal-java

    2023. Reading-eScience-Centre/edal-java. https://github.com/Reading-eScience-Centre/edal-java

  18. [26]

    Sample Size Calculator

    2023. Sample Size Calculator. https://www.calculator.net/sample-size-calculator.html?type=1&cl=95&ci=5&pp= 50&ps=&x=76&y=22

  19. [27]

    Snyk - Developer security - Develop fast

    2023. Snyk - Developer security - Develop fast. Stay secure. https://snyk.io/

  20. [28]

    Software Design Pattern - Wiki

    2023. Software Design Pattern - Wiki. https://en.wikipedia.org/wiki/Software_design_pattern

  21. [29]

    source-code.biz - Professional Source Code for Software Developers

    2023. source-code.biz - Professional Source Code for Software Developers. https://www.source-code.biz/. 19

  22. [30]

    Unidata/netcdf-java

    2023. Unidata/netcdf-java. https://github.com/Unidata/netcdf-java

  23. [31]

    Universal ctags - GitHub

    2023. Universal ctags - GitHub. https://github.com/universal-ctags/ctags

  24. [32]

    vertx-rx

    2023. vertx-rx. https://github.com/vert-x3/vertx-rx

  25. [33]

    What is object-oriented programming? OOP explained in depth

    2023. What is object-oriented programming? OOP explained in depth. https://www.educative.io/blog/object-oriented- programming

  26. [34]

    C/C++ | Snyk User Docs

    2024. C/C++ | Snyk User Docs. https://docs.snyk.io/getting-started/supported-languages-frameworks-and-feature- availability-overview/c-c++

  27. [35]

    Dependency Invversion Principle | Wikipedia

    2024. Dependency Invversion Principle | Wikipedia. https://en.wikipedia.org/wiki/Dependency_inversion_principle

  28. [36]

    Encapsulation | Wikipedia

    2024. Encapsulation | Wikipedia. https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)

  29. [37]

    Inheritance | Wikipedia

    2024. Inheritance | Wikipedia. https://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)

  30. [38]

    Interface segregation principle | Wikipedia

    2024. Interface segregation principle | Wikipedia. https://en.wikipedia.org/wiki/Interface_segregation_principle

  31. [39]

    Java Programming Tutorial Object-oriented Programming (OOP) Basics

    2024. Java Programming Tutorial Object-oriented Programming (OOP) Basics. https://www3.ntu.edu.sg/home/ehchua/ programming/java/J3a_OOPBasics.html

  32. [40]

    Polymorphism | Wikipedia

    2024. Polymorphism | Wikipedia. https://en.wikipedia.org/wiki/Polymorphism_(computer_science)

  33. [41]

    Qurat Ul Ain, Wasi Haider Butt, Muhammad Waseem Anwar, Farooque Azam, and Bilal Maqbool. 2019. A Systematic Review on Code Clone Detection. IEEE Access 7 (2019), 86121–86144. https://doi.org/10.1109/ACCESS.2019.2918202

  34. [42]

    Hamid Abdul Basit and Stan Jarzabek. 2005. Detecting higher-level similarity patterns in programs. ACM Sigsoft Software engineering notes 30, 5 (2005), 156–165

  35. [43]

    Stefan Bellon, Rainer Koschke, Giuliano Antoniol, Jens Krinke, and Ettore Merlo. 2007. Comparison and evaluation of clone detection tools. IEEE Transactions on Software Engineering 33 (9 2007), 577–591. Issue 9. https://doi.org/10.1109/ TSE.2007.70725

  36. [44]

    Michel Chilowicz, Etienne Duris, and Gilles Roussel. 2009. Syntax tree fingerprinting for source code similarity detection. In 2009 IEEE 17th international conference on program comprehension . IEEE, 243–247

  37. [45]

    Ruian Duan, Ashish Bijlani, Meng Xu, Taesoo Kim, and Wenke Lee. 2017. Identifying Open-Source License Violation and 1-Day Security Risk at Large Scale. InProceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security (Dallas, Texas, USA) (CCS ’17) . Asso...

  38. [46]

    Nils Göde and Rainer Koschke. 2009. Incremental clone detection. In Proceedings of the 2009 European Conference on Software Maintenance and Reengineering (ECSMR’09) . 219–228

  39. [47]

    Yaroslav Golubev, Viktor Poletansky, Nikita Povarov, and Timofey Bryksin. 2021. Multi-threshold token-based code clone detection. In Proceedings of the 28th IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER’21)

  40. [48]

    Srikanth, and E

    Syed Mohd Fazalul Haque, V. Srikanth, and E. Sreenivasa Reddy. 2016. Generic Code Cloning method for Detection of Clone Code in Software Development. InInternational Conference on Data Mining and Advanced Computing (SAPIENCE). 340–344

  41. [49]

    Yutao Hu, Deqing Zou, Junru Peng, Yueming Wu, Junjie Shan, and Hai Jin. 2022. TreeCen: Building Tree Graph for Scalable Semantic Code Clone Detection. In37th IEEE/ACM International Conference on Automated Software Engineering. 1–12

  42. [50]

    Wei Hua, Yulei Sui, Yao Wan, Guangzhong Liu, and Guandong Xu. 2021. FCCA: Hybrid Code Representation for Functional Clone Detection Using Attention Networks. IEEE Transactions on Reliability 70, 1 (2021), 304–318

  43. [51]

    Yu-Liang Hung and Shingo Takada. 2020. CPPCD: A Token-Based Approach to Detecting Potential Clones. In IEEE 14th International Workshop on Software Clones (IWSC’20)

  44. [52]

    Shruti Jadon. 2016. Code Clones Detection Using Machine Learning Technique: Support Vector Machine. InProceedings of the 2016 IEEE INTERNATIONAL CONFERENCE ON COMPUTING, COMMUNICATION AND AUTOMATION (ICCCA) . 299–303

  45. [53]

    Lingxiao Jiang, Ghassan Misherghi, Zhendong Su, and Stephane Glondu. 2007. Deckard: Scalable and accurate tree- based detection of code clones. In Proceedings of the 29th International Conference on Software Engineering (ICSE’07) . 96–105

  46. [54]

    Young-Bin Jo, Jihyun Lee, and Cheol-Jung Yoo. 2021. Two-Pass Technique for Clone Detection and Type Classification Using Tree-Based Convolution Neural Network. Applied Sciences-Basel 11, 14 (2021)

  47. [55]

    J Howard Johnson. 1994. Substring matching for clone detection and change tracking. In Proceedings of the 1994 International Conference on Software Maintenance (ICSM’94) . 120–126

  48. [56]

    Toshihiro Kamiya, Shinji Kusumoto, and Katsuro Inoue. 2002. CCFinder: A multilinguistic token-based code clone detection system for large scale source code. IEEE Transactions on Software Engineering 28, 7 (2002), 654–670

  49. [57]

    Seulbae Kim and Heejo Lee. 2018. Software systems at risk: An empirical study of cloned vulnerabilities in practice. Computers & Security 77 (2018), 720–736. 20

  50. [58]

    German, Ali Ouni, Takashi Ishio, and Katsuro Inoue

    Raula Gaikovina Kula, Daniel M. German, Ali Ouni, Takashi Ishio, and Katsuro Inoue. 2017. Do Developers Update Their Library Dependencies? An Empirical Study on the Impact of Security Advisories on Library Migration.Empirical Software Engineering 23 (9 2017), 384–417. Issue 1....

  51. [59]

    Flavius-Mihai Lazar and Ovidiu Banias. 2014. Clone detection algorithm based on the abstract syntax tree approach. In 2014 IEEE 9th IEEE International Symposium on Applied Computational Intelligence and Informatics (SACI) . IEEE, 73–78

  52. [60]

    Liuqing Li, He Feng, Wenjie Zhuang, Na Meng, and Barbara Ryder. 2017. CClearner: A deep learning-based clone detection approach. InProceedings of the 2017 International Conference on Software Maintenance and Evolution (ICSME’17). 249–260

  53. [61]

    Hongliang Liang and Lu Ai. 2021. AST-path Based Compare-Aggregate Network for Code Clone Detection. In Proceedings of the 2021 International Joint Conference on Neural Networks (IJCNN’21)

  54. [62]

    Robert C Martin. 2000. Design principles and design patterns. Object Mentor 1, 34 (2000), 597

  55. [63]

    Lawrence Page, Sergey Brin, Rajeev Motwani, and Terry Winograd. 1998. The PageRank Citation Ranking: Bringing Order to the Web. Stanford Digital Libraries Working Paper (1998)

  56. [64]

    Patenaude, Ettore Merlo, Michel Dagenais, and Bruno Laguë

    JF. Patenaude, Ettore Merlo, Michel Dagenais, and Bruno Laguë. 1999. Extending software quality assessment techniques to java systems. In Proceedings of the 7th International Workshop on Program Comprehension (IWPC’99) . 49–56

  57. [65]

    M. F. Porter. 1980. An algorithm for suffix stripping. Program 14 (3 1980), 130–137. Issue 3. https://doi.org/10.1108/ EB046814/FULL/XML

  58. [66]

    VA Profillidis and GN Botzoris. 2019. Statistical methods for transport demand modeling.Modeling of transport demand (2019), 163–224

  59. [67]

    Chaiyong Ragkhitwetsagul and Jens Krinke. 2017. Using Compilation/Decompilation to Enhance Clone Detection. In Proceedings of the 11th IEEE International Workshop on Software Clones (IWSC) . 8–14

  60. [68]

    Chaiyong Ragkhitwetsagul, Jens Krinke, and Bruno Marnette. 2018. A Picture Is Worth a Thousand Words: Code Clone Detection Based on Image Similarity. In Proceedings of the 12th IEEE International Workshop on Software Clones (IWSC). 44–50

  61. [69]

    Dhavleesh Rattan, Rajesh Bhatia, and Maninder Singh. 2013. Software clone detection: A systematic review.Information and Software Technology 55 (7 2013), 1165–1199. Issue 7. https://doi.org/10.1016/J.INFSOF.2013.01.008

  62. [70]

    Tobias Sager, Abraham Bernstein, Martin Pinzger, and Christoph Kiefer. 2006. Detecting similar Java classes using tree algorithms. In Proceedings of the 2006 international workshop on Mining software repositories . 65–71

  63. [71]

    Tobias Sager and A Coogle. 2006. A Code Google Eclipse Plug-in for Detecting Similar Java Classes. Department of Informatics, University of Zurich (2006)

  64. [72]

    Vaibhav Saini, Farima Farmahinifarahani, Yadong Lu, Pierre Baldi, and Cristina V Lopes. 2018. Oreo: Detection of clones in the twilight zone. In Proceedings of the 26th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software E...

  65. [73]

    Haruaki Tamada, Masahide Nakamura, Akito Monden, and Ken-ichi Matsumoto. 2004. Design and evaluation of birthmarks for detecting theft of java programs.. In IASTED Conf. on Software Engineering . 569–574

  66. [74]

    Bjørnar Tessem, R Alan Whitehurst, and Christopher L Powell. 1998. Retrieval of java classes for case-based reuse. In Advances in Case-Based Reasoning: 4th European Workshop, EWCBR-98 Dublin, Ireland, September 23–25, 1998 Proceedings

  67. [75]

    Min Wang, Pengcheng Wang, and Yun Xu. 2017. CCSharp: An efficient three-phase code clone detector using modified pdgs. In Proceedings of the 24th Asia-Pacific Software Engineering Conference (APSEC’17) . 100–109

  68. [76]

    Pengcheng Wang, Jeffrey Svajlenko, Yanzhao Wu, Yun Xu, and CK. Roy. 2018. CCAligner: A token based large-gap clone detector. In Proceedings of the 40th International Conference on Software Engineering (ICSE’18) . 1066–1077

  69. [77]

    Yuekun Wang, Yuhang Ye, Yueming Wu, Weiwei Zhang, Yinxing Xue, and Yang Liu. 2023. Comparison and Evaluation of Clone Detection Techniques with Different Code Representations. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE) . IEEE, 332–344

  70. [78]

    Huihui Wei and Ming Li. 2017. Supervised deep features for software functional clone detection by exploiting lexical and syntactical information in source code. In Proceedings of the 2017 International Joint Conferences on Artificial Intelligence (IJCAI’17). 3034–3040

  71. [79]

    Seunghoon Woo, Sunghan Park, Seulbae Kim, Heejo Lee, and Hakjoo Oh. 2021. CENTRIS: A Precise and Scalable Approach for Identifying Modified Open-Source Software Reuse. In 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE). IEEE, 860–872

  72. [80]

    Jiahui Wu, Zhengzi Xu, Wei Tang, Lyuye Zhang, Yueming Wu, Chengyue Liu, Kairan Sun, Lida Zhao, and Yang Liu

  73. [81]

    Yueming Wu, Siyue Feng, Deqing Zou, and Hai Jin. 2022. Detecting Semantic Code Clones by Building AST-based Markov Chains Model. In Proceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering 21 (ASE’22)

  74. [82]

    Yueming Wu, Deqing Zou, Shihan Dou, Siru Yang, Wei Yang, Feng Cheng, Hong Liang, and Hai Jin. 2020. SCDetector: Software Functional Clone Detection Based on Semantic Tokens Analysis. In Proceedings of the 35th IEEE/ACM International Conference on Automated Software Engineering...

  75. [83]

    Jian Zhang, Xu Wang, Hongyu Zhang, Hailong Sun, Kaixuan Wang, and Xudong Liu. 2019. A novel neural source code representation based on abstract syntax tree. In Proceedings of the 41st International Conference on Software Engineering (ICSE’19). 783–794

  76. [84]

    Gang Zhao and Jeff Huang. 2018. Deepsim: Deep learning code functional similarity. In Proceedings of the 26th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (FSE’18). 141–151

  77. [85]

    Lida Zhao, Sen Chen, Zhengzi Xu, Chengwei Liu, Lyuye Zhang, Jiahui Wu, Jun Sun, and Yang Liu. 2023. Software Composition Analysis for Vulnerability Detection: An Empirical Study on Java Projects. ESEC/FSE 2023 - Proceedings of the 2023 ACM Joint Meeting on European Software En...

  78. [86]

    Yue Zou, Bihuan Ban, Yinxing Xue, and Yun Xu. 2020. CCGraph: a PDG-based code clone detector with approximate graph matching. In Proceedings of the 35th International Conference on Automated Software Engineering (ASE’20) . 931–942. 22

  79. [2023]

    In 45th IEEE/ACM International Conference on Software Engineering, ICSE 2023, Melbourne, Australia, May 14-20, 2023

    OSSFP: Precise and Scalable C/C++ Third-Party Library Detection using Fingerprinting Functions. In 45th IEEE/ACM International Conference on Software Engineering, ICSE 2023, Melbourne, Australia, May 14-20, 2023 . IEEE, 270–282. https://doi.org/10.1109/ICSE48619.2023.00034

Pith tools

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