JDQuery: Query-Driven Defect Localization for Java Source Code Based on Code Knowledge Graphs

Abstract

Java is one of the most widely used object-oriented programming languages, making accurate and efficient defect localization essential for improving software quality and reliability. Conventional static analysis techniques primarily rely on predefined rules and localized syntactic matching, which may limit their ability to capture complex structural and semantic relationships among program entities. To address these limitations, this paper proposes JDQuery, a query-driven defect localization framework for Java source code based on a code knowledge graph. The framework parses Java source code into abstract syntax trees (ASTs), extracts software entities and their semantic relationships according to a formalized domain ontology, and constructs a unified code knowledge graph that integrates syntactic and semantic information. Based on the structural characteristics of Java defects, defect patterns are translated into Cypher queries, enabling flexible defect localization through graph pattern matching. Experiments on multiple open-source Java projects, including both injected defects and native real-world defects, demonstrate that JDQuery achieves precision values of 97.20% and 92.87% on two projects of different code sizes. A comparative evaluation with PMD further shows that JDQuery achieves substantially higher recall while maintaining comparable precision for the evaluated defects. Efficiency experiments demonstrate that JDQuery maintains millisecond-level query latency even when processing large-scale Java projects.

1. Introduction

Java remains one of the most widely used programming languages in modern software development. Its platform independence and mature ecosystem have made it a popular choice across a wide range of application domains. As Java software systems continue to grow in scale and complexity, defects in source code can lead to system failures, security vulnerabilities, and increased maintenance costs. Therefore, effective detection of defects in Java source code is an important task in software engineering [1].

Java programming defects are unintended or incorrect program constructs and behaviors that may result from violations of programming rules, inconsistent logic, or improper interactions among program components. These defects can exhibit diverse structural and semantic characteristics. Their detection may also require information that extends beyond local code fragments or individual files. Accurate defect localization is therefore important for software quality and reliability. Unlike security vulnerabilities, which primarily concern security-related behaviors and violations of security properties, Java programming defects cover a broader range of programming correctness and behavioral issues. Existing Java static analysis tools, such as PMD (PMD: An extensible cross-language static code analyzer: https://pmd.github.io/ (accessed on 23 August 2026)), commonly apply predefined rules to parsed program structures to identify programming flaws. However, rule-based approaches can make it difficult to express and identify defect patterns that depend on non-local relationships among program elements or across files. This limitation becomes more evident when the information required for detection is distributed across different parts of a program.

Knowledge graphs provide a structured representation of entities and their relationships in complex domains [2,3,4,5]. For Java source code, a code knowledge graph models code entities, including packages, classes, interfaces, and methods, together with their semantic relationships, such as containment, method invocation, inheritance, and exception handling. Compared with conventional ASTs or isolated rule representations, a code knowledge graph integrates syntactic and semantic information into a unified graph structure, enabling query-driven defect localization through expressive graph query patterns [5,6].

This paper introduces JDQuery, a query-driven defect localization for Java source code based on code knowledge graphs. It targets structured Java programming and specification defects that can be represented and queried through a code knowledge graph, rather than attempting to provide comprehensive detection of security vulnerabilities. The main contributions of this work are summarized as follows: First, we propose a unified code knowledge graph model based on a formalized Java domain ontology. The model integrates heterogeneous code artifacts, including code elements, inheritance hierarchies, and cross-file relationships, into a unified semantic representation. Second, we develop a knowledge extraction method that automatically constructs the code knowledge graph from Java source code. The method extracts code entities and semantic relationships across files, providing comprehensive structural and semantic information for defect localization. Third, we formalize 35 common Java defect patterns as declarative graph query patterns and translate them into executable Cypher queries. This query-driven method decouples defect specification from traversal logic, enabling localization of diverse defects through graph pattern matching over the code knowledge graph.

The remainder of this paper is organized as follow: Section 2 reviews related work on Java static defect detection and knowledge graph-based software engineering. Section 3 presents the proposed query-driven defect detection method based on code knowledge graphs. Section 4 reports the experimental design and evaluation results. Section 5 discusses threats to validity. Section 6 concludes this paper and outlines future work.

2. Related Works

2.1. Static Defect Detection Methodologies

Automated software defect detection operates as a pivotal paradigm within quality assurance, broadly categorized into dynamic and static verification methodologies. While dynamic analysis isolates runtime anomalies by executing instrumented binaries against discrete test suites, its diagnostic scope is intrinsically bounded by execution path coverage [7]. Consequently, static defect detection tools have emerged as the preferred alternative, parsing lexical, syntactic, and structural source artifacts without executing the program [8]. The evolution of traditional static analysis exhibits a clear hierarchical progression from primitive lexical processing to deeply integrated semantic tracking [9]. Early foundations primarily relied on linear lexical tokenization and rigid pattern matching [10]. Superficial pattern matching operates in a complete structural vacuum, lacking any syntactic comprehension or type awareness, which inherently yields severe false-positive inflation. To elevate diagnostic precision, compiler-assisted techniques, most notably ASTs, were integrated into modern static analyzers to optimize structural program representations [11]. By parsing source code into a hierarchical tree, AST-based engines capture structured program representations, allowing frameworks to traverse syntax nodes and invoke customized structural rules. This methodology forms the baseline architecture for extensible linting tools such as PMD [12], Checkstyle [13], and the built-in inspection utilities of modern IDEs like IntelliJ IDEA. To bridge the localized gaps of isolated trees and capture deeper execution logic, contemporary platforms have advanced toward comprehensive semantic and inter-procedural analysis. Frameworks like FindBugs [14] and SpotBugs [15] optimize this paradigm by evaluating compiled Java bytecode, successfully isolating defects related to underlying JVM mechanisms. Concurrently, enterprise whole-program static trackers such as SonarQube [16,17] and Coverity [18] combine AST parsing with control-flow graphs and program dependence graphs to track multi-layered data mutations and method invocations across broader software scopes.

Despite the widespread industrial adoption of traditional static analysis tools, these tools exhibit three limitations that limit their overall defect-detection efficacy. First, some tools [8] suffer from severe semantic isolation, relying heavily on localized syntactic patterns and isolated AST nodes that possess no native, direct topological edges linking them to global type definitions or dynamic variable mutations. Second, established rule-based frameworks such as PMD [12] and SonarQube [16] present a paradigm of procedural coupling in rule specification, forcing developers to implement verbose, imperative Java code and manually override complex Visitor design patterns to traverse control-flow paths. This procedural encoding suffers from limited expressiveness, making rule modification error-prone and limiting the flexibility needed to formalize complex, multi-layered vulnerabilities. Third, widely deployed static analyzers such as Checkstyle and SpotBugs remain structurally deficient in executing effective cross-node and cross-file dependency analysis. Because real-world software defects are rarely confined to isolated code blocks but instead manifest through intricate method call chains and complex inheritance graphs [19], these traditional tools struggle to track non-local semantic chains across scattered files, leading to critical path blind spots [20].

2.2. Knowledge Graph Applications in Defect Detection

To overcome the intertwined boundaries among precision, context tracking, and expressiveness, recent academic and industrial efforts have pioneered the application of knowledge graphs to source code analysis [21,22,23]. By converting source code into a unified code knowledge graph, heterogeneous code entities, ranging from high-level packages to granular expressions, are modeled as interconnected nodes, while architectural interactions such as containment, inheritance, and invocation are explicitly represented as semantic edges. This graph-structured paradigm provides a unified representation of both syntactic and semantic information from a relational perspective, effectively dissolving the boundaries of semantic isolation and enabling robust, non-local cross-file dependency analysis. Furthermore, advanced semantic analysis engines such as CodeQL [24] have demonstrated the efficacy of framing defect detection as a relational query-matching problem, enabling users to write object-oriented queries to isolate structural anomalies. However, legacy semantic query frameworks routinely require tedious pre-compilation of large, isolated relational databases for each codebase version, creating steep usage barriers and limiting agility in deployment pipelines. Inspired by the expressive capability of graph-structured representations, this paper proposes JDQuery, a query-driven defect localization framework based on a code knowledge graph. By integrating syntactic and semantic relationships into a unified graph representation, JDQuery formalizes Java defect patterns as declarative graph query patterns and translates them into Cypher queries executed over the constructed code knowledge graph. This query-driven mechanism decouples defect pattern specifications from procedural traversal logic, providing a flexible, extensible, and unified method for Java defect localization.

3. Methods

This section presents the proposed query-driven defect detection method for Java source code based on code knowledge graphs. As illustrated in the overall workflow (Figure 1), the proposed method consists of two main phases, namely code knowledge graph construction and query-driven defect localization, as discussed below:

1.

Specification-Guided Java Code Knowledge Graph Construction: Guided by the Java Language Specification, target source files are parsed into ASTs. Code entities, attributes, and relationships are then extracted from the ASTs and mapped onto a predefined ontology layer to build a persistent code knowledge graph.

2.

Query-Driven Java Defect Localization: Java defect patterns are defined based on the structural and semantic characteristics of different defect types and are subsequently transformed into declarative graph queries. By executing these queries over the structured code knowledge graph, JDQuery identifies graph structures that satisfy the defect patterns, thereby enabling query-driven defect localization.

3.1. Java Code Knowledge Graph Construction

The construction of the Java code knowledge graph includes ontology layer definition, AST generation, instance layer construction, and persistent storage. The purpose of this stage is to transform unstructured Java source code into a structured and queryable graph representation.

3.1.1. Ontology Definition

The ontology layer of the proposed code knowledge graph provides a high-level conceptual model of Java source code and serves as the conceptual schema of the graph, defining the entity types, semantic relationships, and constraints instantiated in the instance layer [25,26]. It is independent of any specific Java project and captures the structural and semantic characteristics that are common across Java source code. To ensure consistency with the Java Language Specification, the ontology is constructed through a systematic analysis of Java lexical and syntactic rules, enabling the formal representation of core code entities and their logical and syntactic dependencies. This ontology-guided representation provides a unified semantic foundation for knowledge extraction and subsequent graph-based defect localization [2,3,4].

In this study, the ontology is manually constructed and formalized using the Web Ontology Language (OWL) standard (The W3C Web Ontology Language (OWL): https://www.w3.org/OWL/ (accessed on 23 August 2026)). In alignment with the OWL specification, Java code elements are modeled as classes in the code knowledge graph, while their characteristics and mutual dependencies are formalized using properties. Specifically, these properties are divided into two categories: data properties and object properties. Data properties capture literal attributes of code entities (e.g., method return types, variable names, or modifier flags), whereas object properties represent semantic or syntactic relationships between different entities (e.g., method–parameter associations, class–method containment, or inheritance links). These two property types collectively define the core code entities, and their interrelationships in accordance with the Java language specification (Java language and virtual machine specifications: https://docs.oracle.com/javase/specs/ (accessed on 23 August 2026)). For example, a Java method construct is defined as a class named Method, while its formal parameter is defined as a class named Parameter. The return type of a method, being a literal attribute, is modeled as a data property named hasMethodType. Conversely, the syntactic relationship between a method and its parameter is modeled as an object property named hasParameter. Figure 2 illustrates a representative subset of the core classes, object properties, and data properties defined in the proposed Java code ontology. The hierarchical visualization demonstrates how Java language constructs are modeled as distinct semantic entities and interconnected through explicitly defined relationships in the knowledge graph.

For presentation clarity, Figure 2 provides a simplified view of the ontology and omits some detailed property names and relationships. Currently, the Java code ontology consists of 45 classes, 51 object properties, and 36 data properties. The ontology elements are not intended to provide an exhaustive representation of all Java code elements. Rather, they cover the core code constructs and semantic relationships required by the current defect detection tasks. The ontology is extensible and can be further enriched with additional classes, properties, and relationships according to the requirements of different analysis tasks and defect patterns.

3.1.2. AST Generation

To extract concrete code facts from the target source code, the raw Java files must first be converted into a structured intermediate representation. This process is accomplished via a compiler front-end component known as a parser, which executes lexical and syntactic analysis to output an AST. The syntactic parsing is divided into two fundamental components: the lexical analyzer and the syntax analyzer [27]. The lexical analyzer ingests the raw Java source text, performs character-level scanning, and segments the continuous text into a sequential stream of meaningful cryptographic units, termed a Token stream. The syntax analyzer takes the generated token stream as input. By validating the tokens against the formal grammar rules defined in the Java language specification, it extracts the hierarchical program structure and constructs the final AST. Subsequently, supplementary program metadata is embedded into the syntax nodes via contextual analysis.

Within the AST, Java code elements are represented as distinct nodes. Furthermore, these nodes contain explicit attributes to store localized metadata. A quintessential example is the line number attribute. The parser automatically detects and logs the exact spatial position (i.e., the starting and ending line numbers) of each code element in the original source file, binding this geometric data directly to the node as a key attribute. In this study, we employ JavaParser (A tool for Java code parsing: https://javaparser.org/ (accessed on 15 May 2026)) to automate the generation of the Java AST.

3.1.3. Instance Layer Construction

The key step in constructing a code knowledge graph is extracting entities and semantic relationships from Java source code to populate the instance layer. The knowledge extraction process operates on the parsed AST, identifying and instantiating code entities, attributes, and relationships as graph elements, as illustrated in Figure 1. During the automated traversal of the AST nodes, the extraction program executes a rigorous mapping mechanism tied to the predefined ontology layer:

• Nodes are mapped to predefined ontology classes to instantiate graph entities.
• Node attributes are mapped to OWL data properties to define entity attributes.
• Syntax and semantic relationships between nodes are mapped to OWL object properties to establish graph relationships.

The following describes the isntacne layer construction process from three aspects: entity extraction, attribute extraction, and relationship extraction, which collectively transform parsed ASTs into structured graph instances.

Entity Extraction. Entity extraction is the first step in constructing the instance layer of the code knowledge graph. Its objective is to identify entities from parsed Java source code and classify them according to the predefined ontology schema. In JDQuery, entity extraction is performed through an in-memory traversal of the AST. For each AST node, the extraction engine determines its syntactic type and instantiates the corresponding ontology class as a graph entity, providing the foundation for subsequent attribute and relationship extraction.

Attribute Extraction. Attribute extraction enriches graph entities with descriptive information obtained from the parsed AST. In JDQuery, AST node attributes are extracted and mapped to the predefined data properties in the ontology, thereby assigning semantic attributes to the corresponding graph entities. The extracted attributes are categorized into two groups: universal attributes, which are shared by most AST nodes (e.g., source code location and code snippets), and type-specific attributes, which describe the characteristics of particular software entities. After extraction, each attribute is associated with its corresponding entity according to the ontology schema, completing the attribute representation in the code knowledge graph.

Relationship Extraction. Relationship extraction establishes semantic connections between graph entities, transforming isolated entities into a connected code knowledge graph. For Java source code, these relationships include both structural dependencies defined by the language syntax, such as containment and inheritance, and semantic dependencies, such as method invocation and exception handling. During AST traversal, the extraction process identifies these relationships and maps them to the predefined OWL object properties in the ontology, thereby constructing semantic edges between graph entities. To support diverse defect localization requirements, the relationship extraction mechanism employs a rule-based design, enabling the incremental incorporation of new relationship types and extraction rules as additional defect patterns are introduced.

3.1.4. Persistent Storage

Although the code knowledge graph can be represented using serialized RDF/XML documents, file-based storage is not suitable for large-scale Java source code analysis because it provides limited scalability and inefficient graph querying. To support efficient storage and query execution, the constructed code knowledge graph is persisted in a graph database. In this work, the code knowledge graph is stored in Neo4j, an open-source graph database that natively supports the property graph model and the Cypher query language. By providing efficient graph traversal and pattern matching, Neo4j enables scalable execution of complex graph queries required for query-driven defect localization.

To bridge the RDF representation and the property graph model, a lossless mapping strategy is adopted. RDF resources are transformed into nodes, ontology classes are mapped to Neo4j labels, data properties are represented as node properties, and object properties are converted into directed relationships connecting graph nodes. This mapping preserves the semantic structure of the original code knowledge graph while enabling efficient graph query execution in Neo4j.

3.2. Query-Driven Defect Localization

After the code knowledge graph has been constructed and stored, defects are localized by executing graph queries. This section presents the proposed query-driven defect localization method over the constructed code knowledge graph. The overall process consists of four phases: defect pattern analysis, query rule formulation, graph query execution, and defect localization result generation.

3.2.1. Defect Pattern Analysis

A defect pattern is a formalized representation of the common structural and semantic characteristics shared by a specific type of software defect [28]. Rather than describing only the syntactic manifestation of a defect, it captures the underlying conditions that consistently lead to defect occurrence across different Java programs. In JDQuery, defect patterns provide the semantic basis for constructing declarative graph queries used for defect localization.

To illustrate the formalization of a Java defect pattern, Listing 1 presents a common design defect in which an abstract class declares public constructors. As shown in Lines 5 and 9 of Listing 1, both the default and parameterized constructors of AbstractClass are declared with the public modifier.

Listing 1. Exemplar code fragment exhibiting Abstract Class Exposing Public Constructors (ACP) defect.

Based on the structural and semantic characteristics of this defect, the corresponding defect pattern is defined by the following rules:

• Code Entity: A graph entity of type ClassOrInterface exists.
• Attribute Constraint: The modifier attribute of the ClassOrInterface entity contains the keyword abstract.
• Relationship Constraint: The ClassOrInterface entity declares one or more ConstructorDeclaration entities whose modifier attribute contains the keyword public.

A code fragment is considered to match this defect pattern only when all above rules are satisfied simultaneously. In this case, the corresponding abstract class is identified as containing the defect. This example illustrates how the structural and semantic characteristics of a Java defect are formalized as a defect pattern. Following the same process, this work systematically defines and formalizes 35 common Java defect patterns derived from widely adopted secure coding guidelines and industry best practices. These defect patterns provide the basis for constructing declarative graph queries, as described in the next section.

3.2.2. Query Rule Formulation

To transform abstract defect patterns into executable graph queries for automated defect localization, JDQuery employs Cypher, the native query language of the Neo4j graph database. Cypher provides a declarative graph query language for specifying structural patterns and semantic constraints over graph data. Compared with procedural graph traversal, Cypher enables defect patterns to be expressed as concise graph query rules while abstracting the underlying traversal process. Consequently, JDQuery adopts a query-driven defect localization paradigm, allowing users to define defect patterns declaratively without implementing traversal algorithms or graph-processing logic.

Taking the previously discussed ACP defect as a foundational benchmark, the corresponding Cypher graph-matching logic is formalized as illustrated in Listing 2.

Listing 2. Cypher query implementation for the ACP pattern.

3.2.3. Defect Detection Execution

After the query rules are defined, they are executed over the Neo4j database, storing the constructed code knowledge graph. Taking the ACP defect as an example, the query first identifies entities labeled as ClassOrInterface and filters those whose modifier attribute contains the keyword abstract. It then traverses the hasConstructorDeclaration relationship to locate the corresponding ConstructorDeclaration entities associated with each abstract class. Finally, the query evaluates the modifier attribute of each constructor to determine whether it contains the keyword public. When all entity, relationship, and attribute constraints defined by the defect pattern are simultaneously satisfied, the corresponding subgraph is identified as a defect instance. The matched entities are then returned as the query results for subsequent defect localization.

3.2.4. Defect Localization Results Generation

The matched entities returned by Neo4j are further processed to generate defect localization results. The query results are parsed into structured objects. Relevant information associated with the matched entities, including the defect type, file path, line number, code fragment, and matched query rule, is extracted from the node properties and graph relationships.

Table 1. The 35 defect types supported by JDQuery and their corresponding knowledge graph elements.

Abbr.	Defect Type	Related Class Types	Data Properties or Object Properties
ACP	Public constructor in an abstract class	ClassOrInterface, Constructor, Modifiers	hasConstructor
ACC	Comparison of objects of atomic types	BinaryExpr, Variable	variableName
BCS	Non-short-circuit logic in Boolean contexts	BinaryExpr	binaryExprOP
CIE	Catching IllegalMonitorStateException	CatchClause, Parameter	hasParameter
CIC	Class or interface name not capitalized	ClassOrInterface	className
CII	Constant defined in an interface	ClassOrInterface, Field	hasField
CNC	Constant name not capitalized	Field, Variable, Modifiers	variableName
DRT	Use of raw types without type parameters	ClassOrInterfaceType	hasValue
DIV	Division by zero	BinaryExpr	binaryExprRight
DIP	Duplicate imports	ImportDeclaration	fileName, hasValue
EFB	Empty finally block	TryStmt, BlockStmt	hasFinallyBlock
EM	Empty method	ClassOrInterface, Method, BlockStmt	hasBlockStmt
ICC	Constant if condition	IfStmt	conditionIs
LCF	Field name not following lower camel case	Field, Modifiers	variableName
LCV	Variable name not following lower camel case	Variable, Modifiers	variableName
MN	Method name not following lower camel case	Method	methodName
ML	Calling wait inside multiple synchronized blocks	SynchronizedStmt, MethodCallExpr	methodName
NTO	Nested ternary operators	ConditionalExpr	–
SA	Self-assignment	AssignExpr	assignValue, assignTarget
SBO	Self binary operations	BinaryExpr	binaryExprRight, binaryExprLeft
SC	Self-comparison	BinaryExpr	binaryExprRight, binaryExprLeft
SMB	Self modulo or division	BinaryExpr	binaryExprOP
SEB	Switch label without break	SwitchEntry, BreakStmt, ReturnStmt, ThrowStmt	labels
SND	Switch without default statement	SwitchStmt, SwitchEntry	hasSwitchEntry
SL	Lock object used as a synchronized lock	SynchronizedStmt, Variable	variableName, elementType
TR	Calling run() on a Thread object	MethodCallExpr, Variable	variableName, elementType, methodScope
TW	Calling wait() on a Thread object	MethodCallExpr, Variable	variableName, elementType, methodScope
TEF	Throwing an exception in a finally block	TryStmt, BlockStmt, ThrowStmt	hasFinallyBlock, hasThrowStmt
TLJ	Java file exceeding 200 lines	JavaFile	beginLine, endLine
TLM	Method exceeding 80 lines	Method	beginLine, endLine
USC	Updating a member variable in a constructor	Constructor, AssignExpr, Field	isStatic, assignTarget
VNI	Variable not initialized	Variable, ForEachStmt	hasVariable, variableInitializer, variableDeclarator
VC	Operations on a volatile variable	FieldDeclaration, UnaryExpr	unaryExprExpression, variableName
WII	Calling wait() inside an if block	IfStmt, MethodCallExpr	methodName
WCC	Constant while condition	WhileStmt	conditionIs

summarizes the 35 defect types supported by JDQuery. It lists their abbreviations (Abbr.), relevant class types, and relevant properties in the Java code knowledge graph. These graph elements represent the key elements used by the corresponding defect detection rules and provide an overview of how the rules are formulated over the knowledge graph. The class types, data properties, and object properties listed in Table 1 are not intended to exhaustively characterize the corresponding defects. Instead, they identify the core graph elements explicitly used by the detection rules. For some defect types, class types, and data properties alone are insufficient to characterize the defect. Their detection, therefore, relies primarily on structural relationships in the knowledge graph. For example, NTO is identified through a directed relationship between two nested ConditionalExpr entities and does not require a specific data property. In such cases, structural relationships encoded in the knowledge graph provide the primary basis for defect detection.

3.3. Summary

This section presents the proposed query-driven defect localization method for Java source code. First, Java source code is transformed into a code knowledge graph through ontology definition, AST parsing, knowledge extraction, and graph database storage. Subsequently, Java defect patterns are formalized as declarative graph query patterns and translated into executable Cypher queries, which are executed over the constructed code knowledge graph to localize defects. By transforming defect localization into a graph query matching process, the proposed method provides a unified representation of both code semantics and defect patterns, enabling the flexible, extensible, and accurate localization of Java source code defects.

4. Results

Based on the proposed method, a prototype system named JDQuery (Java Defect Query) was designed and implemented. JDQuery integrates the complete workflow of code knowledge graph construction and query-driven defect localization, including knowledge extraction, graph storage, defect pattern querying, and defect localization. Based on this prototype, experiments were conducted to evaluate the effectiveness and efficiency of the proposed method.

4.1. Dataset Setting

To evaluate the defect localization effectiveness and efficiency of JDQuery, experiments were conducted on a set of open-source Java projects, as summarized in

Table 2. Provenance and repository configurations of the selected open-source Java benchmarks.

Java Project Name	Owner	Version	Repository URL
commons-cli	Apache	1.5.0	https://github.com/apache/commons-cli (accessed on 15 May 2026)
gson	Google	2.10.0	https://github.com/google/gson (accessed on 15 May 2026)
commons-net	Apache	3.9.0	https://github.com/apache/commons-net (accessed on 15 May 2026)
commons-io	Apache	2.11.0	https://github.com/apache/commons-io (accessed on 15 May 2026)
commons-collections	Apache	4.4	https://github.com/apache/commons-collections (accessed on 15 May 2026)
zookeeper	Apache	3.8.1	https://github.com/apache/zookeeper (accessed on 15 May 2026)
commons-math	Apache	4.0	https://github.com/apache/commons-math (accessed on 15 May 2026)
kafka	Apache	3.4.0	https://github.com/apache/kafka (accessed on 15 May 2026)

. The selected projects are representative Java repositories hosted on GitHub (A platform that hosts projects’ code. https://github.com/ (accessed on 20 May 2026)) and cover a wide range of codebase sizes, ranging from approximately 10,000 to more than 800,000 lines of code (LoCs). This diversity enables the evaluation of JDQuery under projects with different scales and structural characteristics, providing a realistic basis for assessing both defect localization effectiveness and efficiency.

Since existing public defect datasets do not fully cover the 35 Java defect types considered in this study, a dedicated evaluation dataset was constructed using a mutation-based defect injection strategy. We developed a dedicated defect injection tool to automatically generate and inject predefined defective code fragments into the source code of the selected projects. For each defect type, the corresponding defective code snippet and injection rule were implemented in the tool. The tool first identified source-code locations satisfying the predefined injection criteria and then randomly selected suitable locations for defect injection. This process introduced defect instances while preserving the overall structure of the original projects. The injected locations and corresponding defect types were recorded during the injection process and subsequently checked against the modified source code. We ensured that each supported defect type was represented during the injection process.

4.2. Defect Localization Effectiveness

To evaluate the defect localization effectiveness of JDQuery across different project scales, two open-source Java projects were selected as benchmark projects. The projects were categorized into small- and medium-scale groups according to their lines of code (LoCs). Due to the substantial effort required to manually annotate native defects, large-scale projects were not included in the effectiveness evaluation. The selected benchmark projects and their defect distributions are summarized as follows:

• P1 (commons-cli): a small-scale project with 11,548 LoC. It contains 350 artificially injected defects and 104 native defects, resulting in 454 defects in total.
• P2 (commons-io): a medium-scale project with 92,490 LoC. It contains 1292 artificially injected defects and 112 native defects, resulting in 1404 defects in total.

For native defects, we first applied predefined detection rules to identify candidate instances from the project source code. We then manually inspected the candidates against the corresponding source code and available defect evidence to confirm their defect types and exact locations. Only manually verified instances were included in the ground-truth set. False or ambiguous candidates were excluded. We acknowledge that this procedure may not identify all native defects in the projects. Therefore, the resulting ground truth should be understood as a manually verified set of identifiable native defects rather than an exhaustive set of all defects present in the projects.

The defect localization effectiveness of JDQuery was evaluated using four outcomes: True Positives (TPs), True Negatives (TNs), False Positives (FPs), and False Negatives (FNs) [22]. TP denotes the number of defects correctly localized by JDQuery. TN represents the number of non-defective entities correctly identified as non-defective. FP refers to the number of non-defective entities incorrectly reported as defective. FN denotes the number of ground-truth defects missed by JDQuery. Based on these outcomes, Precision, Recall, and F-score were calculated using standard formulations [22]. The overall defect localization results are presented in

Table 3. Overall defect localization effectiveness of JDQuery.

Project	Defects	Reported	TP	TN	FP	FN	Precision (%)	Recall (%)	F-Score (%)
1	454	429	417	41,016	12	37	97.20	91.85	94.45
2	1404	1290	1198	330,360	92	206	92.87	85.33	89.00

.

For P1 (commons-cli), the generated knowledge graph contained 41,482 entities. Among the 454 defect instances in the evaluation dataset, JDQuery reported 429 localization results. Manual inspection confirmed 417 true positives and 12 false positives. The remaining 37 defects were not successfully localized. JDQuery achieved a precision of 97.20%, a recall of 91.85%, and an F-score of 94.45%. These results indicate that JDQuery can effectively localize the evaluated Java defect types while maintaining a very low false-positive rate.

For P2 (commons-io), the generated knowledge graph contained 331,856 entities, and the evaluation dataset contained 1404 ground-truth defects. JDQuery reported 1290 localization results, including 1198 true positives and 92 false positives. It missed 206 defects. The remaining 330,360 non-defective entities were correctly classified as negative. Overall, JDQuery achieved a precision of 92.87%, a recall of 85.33%, and an F-score of 89.00%. These results show that JDQuery maintains a low false-positive rate as the project size increases. However, its recall decreases compared with P1.

The lower recall observed for P2 is mainly associated with defects involving complex data-flow dependencies. Defects related to variable definitions and uses can be effectively identified when their relevant program entities have explicit and localized structural relationships. However, some defects span multiple statements, nested branches, or alternative execution paths. Detecting such defects may require reasoning about data-flow dependencies under different control-flow contexts. The current knowledge graph representation and corresponding Cypher queries may not fully capture all such relationships. Consequently, some defect instances may fail to satisfy the required structural and semantic constraints even when their defect types are within the scope of JDQuery. This limitation is more evident in P2. The number of missed defects increases from 37 in P1 to 206 in P2, while the FNR increases from 8.15% to 14.67%. These results suggest that improving the representation and analysis of control-flow and data-flow dependencies could further improve the recall of JDQuery, particularly for defects that depend on non-local program relationships.

4.3. Comparison Experiment

PMD was selected as the baseline because it is a mature and widely used static analysis tool. To ensure a fair comparison, we identified the defect types that can be detected by both JDQuery and PMD. Because the two tools use different rule systems and analysis mechanisms, the correspondence was established based on the semantic intent of each rule rather than exact rule-name matching. Specifically, we examined the 35 defect types supported by JDQuery and manually mapped each type to a PMD rule when the rule provides detection capability for substantially the same programming or specification violation. Defect types without a semantically equivalent PMD rule were excluded from the comparison. The resulting mapping is presented in

Table 4. Defect types commonly detectable by JDQuery and PMD.

Abbr.	JDQuery Rule	PMD Rule
CIC	Class or interface name not capitalized	ClassNamingConventions
CNC	Constant name not capitalized	FieldNamingConventions
LCF	Field name not following lower camel case	FieldNamingConventions
LCV	Variable name not following lower camel case	LocalVariableNamingConventions
MN	Method name not following lower camel case	MethodNamingConventions
EFB	Empty finally block	EmptyFinallyBlock
SEB	Switch label without break	ImplicitSwitchFallThrough
SND	Switch without default statement	SwitchStmtsShouldHaveDefault
TLJ	Java file exceeding 200 lines	ExcessiveFileLength
TLM	Method exceeding 80 lines	ExcessiveMethodLength

. We identified 10 defect types that can be detected by both tools. This common subset provides a consistent basis for comparison and avoids bias caused by differences in overall rule coverage.

We used PMD 6.51.0 with its default rule configuration and threshold settings. No project-specific parameter tuning was applied. Some PMD rules rely on predefined thresholds. As a result, certain defects may not be reported when they do not satisfy the corresponding threshold conditions. This may lead to a higher false-negative rate. We retained the default configuration to ensure a consistent and reproducible evaluation without project-specific parameter optimization.

Because JDQuery and PMD operate on different analysis spaces, their total numbers of analyzed instances and true-negative counts are not directly comparable. We therefore do not use true-negative-based metrics in the baseline comparison. Instead, both tools are evaluated against the same ground-truth defects within each defect group. We report Precision, Recall, and F1-score as the primary comparison metrics. The results are presented in

Table 5. Comparison of defect detection performance between JDQuery and PMD on P2.

Defect Group	Number	Tool	Reported	TP	FP	FN	Precision (%)	Recall (%)
Injected Defects	101	JDQuery	99	96	3	5	96.97	95.05
		PMD	73	69	4	32	94.52	68.32
Native Real Defects	86	JDQuery	88	86	2	0	97.73	100.00
		PMD	1	1	0	85	100	1.16

.

Table 5 compares the detection performance of JDQuery and PMD on P2. For the injected defects, JDQuery reports 99 instances. Among them, 96 are true positives and 3 are false positives. It achieves a precision of 96.97% and a recall of 95.05%. In comparison, PMD reports 73 instances. It identifies 69 true positives and 4 false positives, resulting in a precision of 94.52% and a recall of 68.32%. The two tools, therefore, achieve comparable precision on the injected defects. JDQuery achieves substantially higher recall.

The relatively high false-negative rate of PMD can be attributed to two main factors. First, some defect types in our dataset are defined using specific code-size thresholds. For example, we consider Java files exceeding 200 lines and methods exceeding 80 lines as defects. However, the corresponding PMD rules use their own predefined thresholds under the default configuration. Since we used PMD 6.51.0 without project-specific parameter tuning, some ground-truth defects may not exceed the default thresholds and are therefore not reported. Second, some defect patterns involve nested program structures. This is particularly relevant to defects involving switch statements, where the relevant pattern may span switch, case, and nested statements. The corresponding PMD rules may not cover all such structural patterns, resulting in additional false negatives. In contrast, JDQuery represents program entities and their structural relationships in a knowledge graph, allowing queries to directly express relationships among nested program elements. These two factors together contribute to the lower recall of PMD on the evaluated defects. We retained the default configuration to ensure a consistent and reproducible comparison without introducing project-specific parameter optimization.

4.4. Efficiency Results

The efficiency of JDQuery was evaluated from two perspectives: the time to construct the code knowledge graph and the time to execute defect queries. Eight open-source Java projects with varying codebase sizes were selected as benchmark projects, ranging from small-scale projects with approximately 10,000 lines of code to large-scale projects exceeding 800,000 lines of code.

The knowledge graph construction results indicate that the construction time increases approximately linearly with the size of the Java project. The construction time ranged from 1.24 s for commons-cli to 106.31 s for kafka. On average, constructing the code knowledge graph required approximately 1 s for every 10,000 lines of Java code.

The defect query results demonstrate that the proposed query-driven defect localization method remains efficient as the project size increases. For a single Java source file, the average query response time was 1.90 ms. At the project level, the defect query execution time ranged from 3.03 ms for commons-cli to 137.50 ms for kafka. The experimental results are summarized in Figure 3. These results demonstrate that the proposed method maintains millisecond-level defect query performance even for large-scale Java projects. Although constructing a code knowledge graph takes more time than executing queries, it is performed only once per project and can be reused for subsequent defect queries. Consequently, the query-driven defect localization process is highly efficient and well-suited to localize multiple defect types within the same code knowledge graph.

5. Discussion and Future Works

The experimental results provide evidence that JDQuery can effectively localize the evaluated Java programming defects across projects of different scales and on both artificially injected and native defects. However, several limitations and threats to validity merit attention.

Regarding internal validity, the observed FNR of 8.15% indicates limitations in tracking transient data-flow changes within complex nested conditional structures. The current code knowledge graph primarily models the structural and semantic relationships of Java source code and does not explicitly represent complete control-flow information. As a result, defect patterns that depend on execution paths or control-flow-dependent data-flow changes may not be fully captured, leading to false negatives. Integrating a control flow graph would require extensions to the current ontology, graph construction process, and defect queries. We therefore leave this extension to future work and plan to investigate how explicit control-flow paths and data-flow dependencies can be incorporated into the knowledge graph to improve the detection of complex defect patterns.

In terms of external validity, the current ontology and extraction engine are closely coupled with the Java Language Specification. This limits the immediate applicability of JDQuery to other programming languages. Extending the framework to dynamically typed languages would introduce additional challenges related to dynamic typing, runtime resolution, and behaviors that cannot be fully determined from static source-code structure. Supporting polyglot systems would also require unified representations of cross-language dependencies and language-specific extraction mechanisms. These extensions would require substantial adaptations to the ontology and extraction layers and are therefore left for future work. In addition, reliance on open-source Java repositories may introduce selection bias because these projects can differ from proprietary enterprise systems in coding styles, design patterns, and defect distributions [29]. Future work will also consider broader datasets and incremental parsing and graph construction mechanisms to improve the applicability of JDQuery in continuous integration environments.

6. Conclusions

In this study, we proposed a knowledge-graph-based defect localization method for Java source code by leveraging semantic and structural information extracted from programs. By transforming Java defect patterns into declarative graph queries, JDQuery establishes a query-driven localization process over the constructed code knowledge graph, enabling the identification of complex defect structures involving cross-node and cross-file relationships. Experiments on open-source Java projects demonstrate the effectiveness of the proposed method, achieving high localization precision, a low false-positive rate, and efficient query execution across projects with different code sizes. These results indicate that representing Java programs as unified code knowledge graphs provides an effective foundation for query-driven defect localization.