How do their APIs compare?

These two projects have fundamentally different notions of "API" — one is an in-process Java class library, the other is a networked scheduling platform — so a fair comparison is really about what kind of API surface each exposes rather than feature-for-feature parity.

joda-time: a Java library API (in-process, type-driven)

Its "API" is a set of Java interfaces and classes consumed by direct method calls, not over the network:

• Read-only contracts like ReadableInstant [src/main/java/org/joda/time/ReadableInstant.java:L17-L34], ReadableDateTime [src/main/java/org/joda/time/ReadableDateTime.java:L20-L31], and ReadablePartial [src/main/java/org/joda/time/ReadablePartial.java:L18-L34] separate "can only read" types from mutable ones.
• Mutable counterparts like ReadWritableDateTime [src/main/java/org/joda/time/ReadWritableDateTime.java:L18-L27] and ReadWritableInstant allow controlled in-place modification, following an immutable-by-default, mutable-by-explicit-opt-in design.
• Utility/comparison classes such as DateTimeComparator [src/main/java/org/joda/time/DateTimeComparator.java:L23-L45] and DateTimeUtils [src/main/java/org/joda/time/DateTimeUtils.java:L28-L35] provide static, thread-safe helper functions.
• Value types like Months and Hours expose typed accessors (getMonths()) and arithmetic (plus(int)) with ISO8601 toString() output (e.g. "P3M", "PT4H") [src/main/java/org/joda/time/Months.java:L253-L275, L402-L407; src/main/java/org/joda/time/Hours.java:L486-L492].
• Extensibility is via the chronology field system (BasicDayOfYearDateTimeField, BasicYearDateTimeField, GJChronology), letting calendar systems plug into the same core interfaces [src/main/java/org/joda/time/chrono/BasicDayOfYearDateTimeField.java:L31-L46].

The design intent is explicitly documented: callers should type their method parameters against the narrowest interface needed (e.g. ReadableInstant if only reading), a convention baked into the Javadoc across these files.

xxl-job: a networked scheduler API (HTTP/RPC between admin and executors)

xxl-job's API surface is about coordinating distributed processes rather than in-memory types:

• The admin module exposes web controllers, e.g. IndexController [xxl-job-admin/src/main/java/com/xxl/job/admin/framework/controller/IndexController.java:L1-L34], built on Spring MVC (@Controller, @RequestMapping, @ResponseBody).
• Trigger semantics are modeled as an enum, TriggerTypeEnum (MANUAL, CRON, RETRY, PARENT, API, MISFIRE), representing how a job execution was invoked [xxl-job-admin/src/main/java/com/xxl/job/admin/business/scheduler/trigger/TriggerTypeEnum.java:L10-L26].
• Executor selection for a distributed job is itself an "API" of pluggable routing strategies, e.g. ExecutorRouteConsistentHash, which maps jobs onto a machine pool using consistent hashing with virtual nodes [xxl-job-admin/src/main/java/com/xxl/job/admin/business/scheduler/route/strategy/ExecutorRouteConsistentHash.java:L1-L19].
• Persistence access is via MyBatis mapper interfaces like XxlJobLogGlueMapper [xxl-job-admin/src/main/java/com/xxl/job/admin/business/mapper/XxlJobLogGlueMapper.java:L14-L24], a data-access API layer rather than a public consumer-facing one.
• Deployment/runtime wiring (admin talking to executors over configured addresses) is visible in the docker-compose setup, e.g. xxl.job.admin.addresses pointing executors at the admin service [docker/docker-compose.yml:L56-L69].

Summary of the contrast

• joda-time's API is a type system — interfaces/classes for compile-time safety and semantic clar