[yogthos]

Implements RFC 0014.

The runtime carried the mapping from host class names to the library that installs them — jolt.crypto, io.github.jolt-lang/jolt-crypto, jolt.socket, jolt.time, named in host-static.ss. About 140 of that file's 552 lines were that bookkeeping, in two parallel mechanisms (a bespoke one for java.time and the general lib-class-providers) invoked side by side at five call sites, plus a sixth copy in build.ss whose comment said it "mirrors the runtime predicates".

That was not untidiness. Core decided what a class meant, so providers were unswappable and adding one needed a jolt release. And the list was hand-synced — the source said so out loud, next to a recorded instance of the bug it caused:

This list has to name EVERY class jolt-lang/time registers, in both the simple and the fully-qualified spelling. […] DateTimeFormatterBuilder being absent kept malli's transform.cljc from loading while the qualified spelling worked. When the library grows a class, add it here.

Why declaration, and not register-on-load

A provider cannot register itself as it loads: the miss happens before it has loaded, which is the entire purpose of the mechanism. So the mapping arrives as data, ahead of the load:

;; jolt-lang/db
:jolt/provides {db.jdbc-shim ["java.sql.ResultSet" "java.sql.Connection" …]}

jolt.deps collects it through the walk it already does for :jolt/native; apply-project! installs it before any user code compiles. Registration at load is unchanged. Fully-qualified only — the runtime derives the simple spelling.

What core keeps

Only the classes core implements: jolt.time.base's java.time value types (RFC 0008) and jolt.socket's java.net surface, as core-class-providers seeding the same table, carrying no coordinate because no dependency supplies them. build.ss now asks lib-provider-for rather than restating its rules.

Decisions

• Conflicts error at resolve time naming both claimants. Whichever won would decide what java.sql.Connection means program-wide, and the loser's shim would be half-installed — registered for the classes nobody else claimed, silently absent for the rest.
• A claim on a class the runtime already implements is refused — checked against the statics/ctor tables, not the hierarchy. The hierarchy knows names it does not implement (java.time.ZoneId is in it so isa? answers correctly), and checking it rejected every provider for the classes the mechanism exists to serve.

Errors no longer name a library

No dependency provides java.time.ZoneOffset — a concrete implementation of the
JDK classes must be provided.

Which library supplies java.sql is not the runtime's to say, and a caller may write the shim themselves. Two unit tests pinned the old wording — which is how deliberate that message was; they assert the general form now, plus a third asserting no library is named, so the coupling cannot return as a string. A provider that is declared but raised while loading still names itself: that is the caller's own dependency read back from their own deps.edn, and the fix is the opposite of adding something.

Verified

make test — 93 ci targets, 3 test targets, clean. The gate caught four things targeted testing did not: the two deps-alias fixtures needed declarations; the lib coordinate is a symbol the failed-to-load message string-appends; build-app supplies providers on its own :paths (the project's-own-declaration case); and the new jolt.host seam had to be added to jolt-host-manifest.txt.

Declarations are already merged in jolt-lang/db#17, jolt-lang/time#11 and jolt-lang/crypto#6.