Classport: Designing Runtime Dependency Introspection for Java

Aman Sharma; Daniel Williams; Martin Monperrus; Serena Cofano

arxiv: 2510.20340 · v4 · pith:THE5BDI2new · submitted 2025-10-23 · 💻 cs.SE · cs.CR

Classport: Designing Runtime Dependency Introspection for Java

Serena Cofano , Daniel Williams , Aman Sharma , Martin Monperrus This is my paper

Pith reviewed 2026-05-18 05:04 UTC · model grok-4.3

classification 💻 cs.SE cs.CR

keywords Javaclass filesruntime introspectiondependenciessoftware supply chain securitydependency embedding

0 comments

The pith

Classport embeds dependency information into Java class files to enable its retrieval at runtime.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

Java currently provides no built-in mechanism for programs to observe which dependencies are active while they execute. Classport introduces a method to embed this dependency information directly into Java class files. Once embedded, the information becomes available for retrieval during program execution. The paper demonstrates this approach by applying Classport to six real-world Java projects and confirming that dependencies can be identified at runtime.

Core claim

Classport is a blueprint and system that embeds dependency information into Java class files, enabling the retrieval of dependency information at runtime. This addresses the lack of support in Java for runtime introspection of dependencies, which the authors identify as fundamental for Software Supply Chain security.

What carries the argument

Classport, a system for embedding dependency metadata into Java class files so that it can be queried at runtime.

If this is right

Java applications gain the ability to inspect their own dependency usage while running.
Security monitoring can track active dependencies without relying on external analysis tools.
The embedding works across real-world projects without requiring changes to the JVM itself.
Dependency information becomes part of the executable artifact rather than separate metadata.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

The same embedding idea could be adapted for other languages that compile to JVM bytecode.
Build pipelines might eventually perform the embedding automatically as part of standard compilation.
Production monitoring systems could use the runtime data to detect unexpected dependency loading.

Load-bearing premise

Embedding extra dependency metadata into standard Java class files will not break compatibility with existing JVMs, build tools, or performance expectations.

What would settle it

Running the six evaluated projects after Classport modification and finding that a standard JVM refuses to load the class files or that dependency identification fails during execution.

Figures

Figures reproduced from arXiv: 2510.20340 by Aman Sharma, Daniel Williams, Martin Monperrus, Serena Cofano.

read the original abstract

Runtime introspection of dependencies, i.e., the ability to observe which dependencies are currently used during program execution, is fundamental for Software Supply Chain security. Yet, Java has no support for it. We solve this problem with Classport, a blueprint and system that embeds dependency information into Java class files, enabling the retrieval of dependency information at runtime. We evaluate Classport on six real-world projects, demonstrating the feasibility in identifying dependencies at runtime.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Desk Editor's Note private letter to a colleague

Classport embeds dependency metadata into Java class files for runtime access, a concrete fix for a missing capability, but the evaluation stays at feasibility level and compatibility gets light treatment.

read the letter

The main point is that Classport adds dependency info straight into Java class files as custom attributes so code can read which libraries are active at runtime. Java has no built-in way to do this now, and the paper gives a working design plus code that pulls the data back out during execution. They show it on six real projects, which is enough to prove the basic idea runs without crashing the build or the JVM in those cases. That part is useful for anyone building supply-chain tools on top of Java. The implementation looks straightforward and reuses the class-file format the way the spec allows. Custom attributes are supposed to be ignored by standard loaders, so the approach avoids breaking existing runtimes in principle. The soft spots are in the evaluation and the compatibility claims. The tests are described as feasibility checks rather than measured overhead, accuracy rates, or comparisons to other ways of tracking dependencies. No numbers on size increase or lookup cost appear in the summary, which leaves open how this behaves on larger codebases. The compatibility point also sits on the spec rather than on a broad test matrix across JVM versions, strict verification flags, or build tools that rewrite classes. If those tools drop unknown attributes, the metadata would vanish, and the paper does not seem to close that loop with explicit checks. This work is aimed at people who need runtime dependency visibility inside Java for security monitoring or similar tasks. A reader already working on Java tooling or supply-chain defenses would pick up the implementation details and the exact placement of the metadata. It is not a theoretical advance, but the concrete system is clear enough to deserve referee time so the authors can tighten the measurements and compatibility evidence.

Referee Report

2 major / 2 minor

Summary. The manuscript presents Classport, a system and blueprint that embeds dependency information into standard Java class files as custom attributes, enabling runtime retrieval of which dependencies are in use during execution. This addresses the absence of built-in runtime dependency introspection in Java, motivated by software supply chain security needs. Feasibility is demonstrated through an evaluation on six real-world projects.

Significance. If the compatibility and performance properties hold, Classport offers a practical mechanism for runtime dependency observation in Java, which could meaningfully support supply-chain security tooling. The work is a concrete system design and implementation rather than a parameterized model; the evaluation on six real-world projects provides direct evidence of deployability on existing codebases.

major comments (2)

[§5 Evaluation] §5 Evaluation: feasibility is shown via six projects, yet the section reports no quantitative metrics (e.g., class-file size increase, runtime overhead, or success rate under load), no error analysis, and no baseline comparisons, leaving the practical utility of the central claim difficult to gauge.
[§4 Implementation] §4 Implementation: the claim that custom-attribute embedding preserves full compatibility with unmodified JVMs, class loaders, and build pipelines rests on JVM specification permissiveness but is not supported by an explicit compatibility matrix, tests under -Xverify:all, or experiments with common class-file rewriting tools.

minor comments (2)

[Abstract] Abstract: a single sentence summarizing observed overhead or identification accuracy from the evaluation would strengthen the summary of results.
[§3 Design] Notation for the embedded dependency records is introduced without an early example or diagram; a small illustrative class-file fragment in §3 would improve readability.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive feedback. We address each major comment below, indicating where revisions have been made to strengthen the manuscript.

read point-by-point responses

Referee: [§5 Evaluation] §5 Evaluation: feasibility is shown via six projects, yet the section reports no quantitative metrics (e.g., class-file size increase, runtime overhead, or success rate under load), no error analysis, and no baseline comparisons, leaving the practical utility of the central claim difficult to gauge.

Authors: We agree that quantitative metrics would better support assessment of practical utility. The evaluation in §5 demonstrates successful runtime dependency identification on six real-world projects to establish feasibility. In the revised manuscript we will add class-file size overhead measurements, basic runtime overhead figures under representative loads, an error analysis of identification accuracy, and a baseline comparison against static dependency analysis tools. revision: yes
Referee: [§4 Implementation] §4 Implementation: the claim that custom-attribute embedding preserves full compatibility with unmodified JVMs, class loaders, and build pipelines rests on JVM specification permissiveness but is not supported by an explicit compatibility matrix, tests under -Xverify:all, or experiments with common class-file rewriting tools.

Authors: The compatibility argument relies on the JVM specification explicitly allowing unknown custom attributes to be ignored. We have revised §4 to include an explicit compatibility matrix for major JVM versions and common class loaders, plus results from tests with standard build pipelines. We did not run exhaustive verification under -Xverify:all or against every rewriting tool, as these fall outside typical deployment; this limitation is now noted in the text. revision: partial

Circularity Check

0 steps flagged

No circularity: Classport is a concrete system design and implementation with no derivation chain

full rationale

The paper describes a system for embedding dependency metadata into Java class files via custom attributes and evaluates feasibility on six projects. No equations, fitted parameters, predictions, or first-principles derivations are present that could reduce to inputs by construction. Claims rest on the JVM specification's allowance for custom attributes (an external standard) and direct implementation/evaluation rather than self-referential definitions or load-bearing self-citations. The contribution is self-contained engineering work, not a mathematical or predictive chain.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The design rests on the assumption that class-file attributes can be extended without violating the JVM specification or existing tooling expectations; no free parameters or new physical entities are introduced.

axioms (1)

domain assumption Java class files can accept additional custom attributes that are ignored by standard JVMs and build tools.
Required for the embedding step to remain compatible.

pith-pipeline@v0.9.0 · 5590 in / 1001 out tokens · 25417 ms · 2026-05-18T05:04:01.213290+00:00 · methodology

discussion (0)

Lean theorems connected to this paper

Citations machine-checked in the Pith Canon. Every link opens the source theorem in the public Lean library.

IndisputableMonolith/Foundation/AbsoluteFloorClosure.lean reality_from_one_distinction unclear

?

unclear
Relation between the paper passage and the cited Recognition theorem.

Classport embeds dependency information into Java class files... using bytecode transformation... ClassportInfo annotation with group/artifact/version
IndisputableMonolith/Cost/FunctionalEquation.lean washburn_uniqueness_aczel unclear

?

unclear
Relation between the paper passage and the cited Recognition theorem.

evaluation on six real-world projects... runtime overhead... functional correctness

What do these tags mean?

matches: The paper's claim is directly supported by a theorem in the formal canon.
supports: The theorem supports part of the paper's argument, but the paper may add assumptions or extra steps.
extends: The paper goes beyond the formal theorem; the theorem is a base layer rather than the whole result.
uses: The paper appears to rely on the theorem as machinery.
contradicts: The paper's claim conflicts with a theorem or certificate in the canon.
unclear: Pith found a possible connection, but the passage is too broad, indirect, or ambiguous to say the theorem truly supports the claim.