DALEQ: Java Bytecode Equivalence Tool

• DALEQ is a Java bytecode equivalence tool that defines level 3 equivalence by transforming bytecode into normalized relational databases.
• It utilizes ASM for bytecode disassembly and the Soufflé datalog engine for rule-based normalization, ensuring reliable secure rebuild verification.
• The tool generates detailed provenance via derivation trees, significantly reducing manual inspection in supply-chain security workflows.

DALEQ is a Java bytecode equivalence tool for the practical setting of secure rebuilds, where independently rebuilt .jar or .class files are often not bitwise identical to the originals even when they are intended to be functionally the same. It was introduced to support supply-chain verification in contexts such as Oracle’s Build-From-Source and Google’s Assured Open Source, where engineers need to determine whether a rebuilt artifact is a safe substitute for the upstream one without relying on exact binary identity. Its central mechanism is to disassemble bytecode into a relational database, normalize that database with datalog rules, and compare the normalized outputs, while also producing readable provenance for both equivalence and non-equivalence judgments (Dietrich et al., 3 Aug 2025).

1. Problem formulation and intended equivalence relation

DALEQ addresses the gap between two unsatisfactory criteria for rebuilt Java artifacts. Bitwise equality is too strict for realistic rebuilds, while full behavioral equivalence is undecidable. The paper therefore defines a practical equivalence relation $\simeq$ for Java bytecode such that

$$b_1 \simeq b_2 \implies b_1 \text{ and } b_2 \text{ have the same behaviour.}$$

Equivalence is established by transforming both bytecodes and comparing the transformed outputs: $$b_1 \simeq b_2 \quad \text{iff} \quad transf(b_1) = transf(b_2).$$

This formulation places DALEQ squarely in the domain of reproducible builds and supply-chain security. Secure rebuild programs compare binaries rebuilt in a hardened environment against developer-published binaries, for example on Maven Central. Since exact bitwise reproducibility is often not achieved, the operational question is whether the artifacts are nevertheless equivalent enough to be safely substituted. DALEQ was designed to reduce the labor-intensive and error-prone manual effort otherwise required to establish that judgment (Dietrich et al., 3 Aug 2025).

The design target is what the paper calls level 3 equivalence. The stated goals are that the equivalence relation is proper—reflexive, symmetric, and transitive—that equivalent classes should have the same behavior, that semantically equivalent instruction sequences should count as equivalent, and that provenance should be generated for both equivalence and non-equivalence. This suggests a deliberately operational notion of bytecode equivalence: stronger than syntactic comparison after trivial renaming, but more conservative than unrestricted semantic reasoning.

2. Extraction and relational representation

DALEQ begins by disassembling Java bytecode with ASM and converting it into a relational representation called the EDB (extensional database). The EDB is a set of facts stored as tab-separated files, one file per predicate. Extracted facts include global class-level information such as superclass, interfaces, annotations, access flags, fields, and methods, together with instruction-level facts for JVM bytecode instructions (Dietrich et al., 3 Aug 2025).

Some normalization is already performed during extraction. Constant-pool references are resolved to symbolic names such as class/method/descriptor triples; labels are renamed canonically as label1, label2, and so on; unused labels are dropped; and line number tables are ignored because they are treated as build noise. In the paper’s equivalence hierarchy, direct comparison of EDBs corresponds to level 2 equivalence: semantically irrelevant details like line numbers and unused labels are removed, but only isomorphic renaming such as label renaming is performed.

This relational abstraction is roughly comparable to javap, but it is more structured and is intended to support rule-based normalization. The key point is that DALEQ does not treat bytecode as an opaque string of instructions. It converts bytecode into a fact database on which logic rules can operate compositionally. A plausible implication is that this choice makes provenance and controlled extensibility easier than in ad hoc text-rewriting pipelines.

3. Datalog normalization and the level 3 comparison pipeline

The second stage uses the Soufflé datalog engine to derive an IDB (intensional database) from the EDB. The IDB is the normalized representation used for equivalence checking. The baseline rule set maps each EDB fact to a corresponding IDB fact, and a generic IDB_INSTRUCTION predicate is also populated so that rules can reason about instruction patterns. Custom normalization rules are stored as separate .souffle files and loaded at runtime (Dietrich et al., 3 Aug 2025).

The current normalization patterns listed in the paper are the following:

• R1 Null checks in method reference operator
• R2 Redundant checkcast instructions
• R3 Inline $values() method in enumerations
• R4 Ignore bytecode versions
• R5 Invocation type of root methods in java.lang.Object on an object declared using an interface type
• R6 Anonymous inner classes are always implicitly final, but compilers set the flag inconsistently

The rule set is explicitly selective. Some patterns from JNorm were intentionally not implemented because they are rare or unsound. The paper gives two concrete examples: removing synthetic methods would be unsound because those methods can affect program semantics, and “buffer method invocation” normalization was rejected because it could make two classes look equivalent even when downstream behavior differs. The paper also distinguishes between sound rules, which should preserve behavioral equivalence, and soundy rules, which may collapse subtle differences observable through reflection or similar mechanisms. Because DALEQ is modular, soundy rules can be removed if a stricter analysis is required.

A representative example is R1, involving Object::getClass and Objects.requireNonNull. The transformation would be unsound if applied blindly because stack contents differ, but in compiler-generated code it is guarded by surrounding DUP and POP instructions, so the datalog rule checks that context in its body. This illustrates DALEQ’s rule philosophy: normalize only when the bytecode context supports the intended behavioral interpretation.

After normalization, DALEQ performs a final projection step. The IDB still contains auxiliary information not needed for equivalence, especially derivation identifiers and instruction counters. Projection removes these terms, the projected IDB is printed as text, and the two outputs are compared. If the projected IDBs are identical, DALEQ declares equivalence. The formal criterion remains

$$b_1 \simeq b_2 \quad \text{iff} \quad transf(b_1) = transf(b_2),$$

where transf is implemented as EDB extraction followed by IDB normalization and projection. In the paper’s terminology, IDB comparison is level 3 equivalence (Dietrich et al., 3 Aug 2025).

4. Provenance, explanations, and proof objects

A defining feature of DALEQ is that equivalence judgments are accompanied by readable provenance. Each extracted fact receives a unique identifier such as F1 or F2. When a datalog rule derives a new fact, DALEQ constructs a composite identifier that records the rule used and the supporting fact identifiers. The paper gives the example

$\texttt{R\_REMOVE\_BYTECODE\_VERSION[F42]}$

for a fact derived from source fact F42 (Dietrich et al., 3 Aug 2025).

These constructed identifiers form a small provenance language. The paper mentions a grammar for such identifiers and a parser that converts them into derivation trees. The trees are rendered in an HTML report, allowing navigation from normalized facts back to extracted facts and the rules that produced them. For equivalence, the explanatory artifact is thus a datalog derivation proof: extracted fact IDs identify source facts, each inferred fact records its rule and dependencies, and the report visualizes those dependencies as trees. For non-equivalence, the provenance is provided by standard diff reports over the projected IDBs.

This provenance model is central to DALEQ’s role in secure rebuild workflows. Existing tools can help compare binaries, but the paper argues that they fall short of providing provenance, understood as a readable explanation of why two binaries are equivalent or not. DALEQ’s output is plain text, so ordinary diff tools remain usable, while the derivation traces explain how normalization eliminated benign differences. This suggests that the tool is intended not merely to automate a decision, but to support auditability and post hoc justification.

5. Industrial-scale evaluation and comparison with existing tools

The evaluation uses datasets from a previous benchmark that compare Maven Central artifacts with rebuilt artifacts produced by trusted providers. The paper reports two datasets: mvnc vs obfs, with 1,922 jars and 135,425 classes, and mvnc vs gaoss, with 792 jars and 130,265 classes. Some jars contained no .class files and were excluded. The total scale is 2,714 pairs of jars and 265,690 class pairs. The source code for the artifacts was checked to be equivalent using an AST-based source comparison that ignores formatting and comments (Dietrich et al., 3 Aug 2025).

Bitwise differences are common, but unevenly distributed. For mvnc vs obfs, the paper reports 2,158 non-equal classes, or 1.59%. For mvnc vs gaoss, it reports 33,470 non-equal classes, or 25.69%. Thus, gaoss builds diverged from Maven Central much more often than obfs builds.

Among the non-bitwise-equal class pairs, DALEQ could still establish equivalence for 1,854 / 2,158 = 85.91% for mvnc vs obfs and 30,390 / 33,470 = 90.80% for mvnc vs gaoss. The paper interprets this as a substantial reduction in the number of cases requiring manual inspection.

The comparison baseline consists of two existing tools: javap -c -p and jnorm version 1.0.0 with -n. javap is treated as trusted, standard, and always available, but limited to low-level disassembly and missing many equivalence-preserving normalizations. jnorm was the best-performing tool in an earlier study, but it was built for similarity analysis rather than equivalence checking and includes rules considered unsound or too aggressive in this setting.

On non-bitwise-equal classes, the reported equivalence counts are as follows:

Comparison	javap equivalent	jnorm equivalent	DALEQ equivalent
mvnc vs obfs	975 (45.18%)	1,404 (65.06%)	1,854 (85.91%)
mvnc vs gaoss	11,741 (35.08%)	27,079 (80.90%)	30,390 (90.80%)

The paper also reports errors for jnorm: 5 errors for mvnc vs obfs and 461 errors for mvnc vs gaoss. DALEQ successfully analyzed all classes in the dataset. In this evaluation, it therefore outperformed both baselines in recovering equivalence among non-bitwise-equal classes (Dietrich et al., 3 Aug 2025).

The practical cost model is also discussed. On a large library such as guava-33.4.0-jre.jar with 2,018 class files, even if 20% need normalization analysis, projected IDB computation would take under 23 minutes on the test machine, while typical libraries take only a few minutes. This situates DALEQ as a tool intended for operational deployment rather than only small-scale experiments.

6. Residual differences, assumptions, and limitations

DALEQ does not claim to be exhaustive. The paper analyzes remaining non-equivalent cases and identifies recurring patterns: CHECKCAST, CONSTANT, SBINIT (StringBuilder initialization), SIGNTR (missing signature attributes), SYNMET (synthetic methods), SYNFLD (synthetic fields), ANNO (changed annotations), and ACCESS (changed access flags) (Dietrich et al., 3 Aug 2025).

Some of these categories are treated as candidates for future soundy rules, especially SIGNTR and ACCESS. Others may indicate genuine issues. The CHECKCAST case is singled out because an extra cast can change control flow by throwing a runtime exception, and CONSTANT differences may indicate a real security issue and deserve investigation. The paper also notes that some differences arise from compiler or toolchain variation rather than behavior: synthetic method and field naming can vary, annotations may differ subtly, access flags can vary, and string builder initialization may be compiled in different but semantically equivalent ways.

Several explicit limitations are stated. The current rule set does not cover all equivalence-preserving transformations. Some rules are deliberately omitted because they would be unsound. Some soundy rules may ignore differences observable via reflection. Certain normalization patterns would require reasoning about an entire nest of classes rather than one class at a time, which DALEQ does not currently do. The approach assumes deterministic extraction and normalization when inferring equivalence for identical inputs. It checked source equivalence only as an additional assumption, not full source provenance correctness. The paper also notes that JavaBEPEnv and JavaBEPFix were not evaluated because they were not publicly available.

These limitations are directly connected to a common misconception: DALEQ is not a decision procedure for full behavioral equivalence. Its criterion is a practical, rule-bounded normalization equivalence intended to imply same behavior under the assumptions encoded in the rules. The distinction between sound and soundy rules makes this explicit. A plausible implication is that DALEQ is best understood as a conservative, explainable equivalence checker for secure rebuild triage, not as a complete semantic verifier.

7. Position within secure rebuild workflows

Within secure rebuild pipelines, DALEQ’s main contribution is to automate the judgment that a rebuilt artifact is a safe substitute for an upstream artifact even when the two are not bitwise identical. Its architecture combines structured bytecode extraction, datalog-based normalization, a projection-based equality test, and proof-producing provenance. In the paper’s industrial evaluation, this combination substantially reduced the manual effort required to assess non-bitwise-equivalent artifacts and identified more artifacts rebuilt from the same code as equivalent than the baseline tools, even when no behavioral differences were present (Dietrich et al., 3 Aug 2025).

The broader significance of DALEQ lies in its treatment of explanation as a first-class output. For equivalence, it provides derivation trees that show how normalized facts were obtained. For non-equivalence, it provides textual diffs over projected normalized representations. This dual provenance model aligns with the paper’s design goal that provenance should be generated for both equivalence and non-equivalence.

In this sense, DALEQ occupies a specific niche in supply-chain security for Java: it mediates between strict reproducibility checks and costly human inspection. It does so by defining a practical equivalence relation, implementing that relation through a relational and datalog-based normalization pipeline, and making the resulting judgments inspectable rather than opaque.