How do their APIs compare?

Comparing the two projects at the API level, they operate on very different problem domains, so the comparison is really about design philosophy and scope rather than overlapping functionality.

google/exoplayer — media playback API

ExoPlayer's public API is organized around media components and extensibility, not a single monolithic library. From the retrieved code, you can see this pattern clearly in the extensions/ modules, each of which wraps a native or third-party library behind a small, focused Java API:

• FlacLibrary / Gav1Library — thin static-utility classes that "configure and query the underlying native library" via LibraryLoader [extensions/flac/.../FlacLibrary.java:L20-L29] [extensions/av1/.../Gav1Library.java:L20-L29]. These follow an identical shape across codec extensions, suggesting a consistent internal convention for native library bindings.
• CronetUtil — exposes engine-building/selection logic (e.g. CronetProviderComparator) for choosing between HTTP stack providers [extensions/cronet/.../CronetUtil.java:L127-L167], showing the API favors pluggable strategy objects (Comparator) over hardcoded logic.
• ByteArrayUploadDataProvider — package-private helper implementing a third-party interface (UploadDataProvider) [extensions/cronet/.../ByteArrayUploadDataProvider.java:L33-L44], illustrating that ExoPlayer often adapts external SDK interfaces rather than defining everything itself.
• CastUtils — static helper methods bridging Cast SDK types to ExoPlayer's own time units (Util.msToUs, C.TIME_UNSET) [extensions/cast/.../CastUtils.java:L44-L50].

A notable API-wide signal: essentially every public/package class carries an explicit @Deprecated annotation and Javadoc pointing to the AndroidX Media3 migration guide (e.g. [extensions/cronet/.../ByteArrayUploadDataProvider.java:L26-L31], [extensions/flac/.../FlacLibrary.java:L22-L28]). This is a structural, project-wide API marker, not incidental — the whole surface is frozen and redirects consumers elsewhere. This aligns with RepoPilot's verdict of WAIT — Slowing, last commit 9mo ago and the low OpenSSF Scorecard (3.1/10, with CI-Tests, Dependency-Update-Tool, and SAST all at 0/10), reinforcing that this API should be treated as legacy/frozen rather than actively evolving.

jodaorg/joda-time — date-time value-type API

Joda-Time's API is built around immutable interfaces and factory-style static methods for representing time concepts:

• ReadableInstant and ReadableDuration are minimal, read-only interfaces representing an instant and an exact millisecond duration respectively [ReadableInstant.java:L17-L37] [ReadableDuration.java:L17-L38]. Both explicitly document that compareTo was intentionally moved out of the interface in 2.0 for binary-compatibility reasons — a good example of Joda-Time's strong API stability discipline.
• Interval extends BaseInterval and composes with Chronology/formatters (ISOChronology, ISODateTimeFormat, ISOPeriodFormat) [Interval.java:L1-L51], showing the API is deeply compositional — most concrete types are built from smaller readable/base abstractions rather than being extension wrappers like ExoPlayer's.
• PeriodType uses cached singleton factory methods (yearMonthDay(), yearDay(), yearMonthDayTime()) that lazily construct and cache PeriodType instances with explicit field-index arrays [PeriodType.java:L131-L170, L251-L290]. It also exposes fluent "removal" methods like withMonthsRemoved(), withDaysRemoved() [PeriodType.java:L731-L770], reflecting an immutable-builder style API.
• Partial enforces strict invariants on field ordering at construction time via detailed IllegalArgumentException checks (largest-to-smallest field order, no duplicates) [Partial.java:L228-L267] — a much more validation-heavy, defensive API style than what's visible in ExoPlayer's extension wrapp