How do their APIs compare?

These two repositories serve very different purposes, so their "APIs" aren't really comparable in kind — one is a learning/reference repo, the other is a mature, purpose-built library.

jcsprout doesn't really expose a stable public API in the traditional sense. It's a collection of standalone demo/example classes illustrating Java concepts — concurrency, collections, algorithms, proxies, caching, etc. Each class tends to be self-contained with a main method for demonstration rather than being designed for reuse by other code. Examples in the retrieved data:

• [src/main/java/com/crossoverjie/actual/Search.java:L61-L78] — a main method that spins up threads and calls a static search/addWord utility, used as a runnable demo rather than an API surface.
• [src/main/java/com/crossoverjie/actual/LRUAbstractMap.java:L1-L26] — a custom LRU map implementation with class-level Javadoc describing its intended behavior (eviction, timeout callbacks), but it's a teaching implementation, not a hardened library type.
• [src/main/java/com/crossoverjie/algorithm/BloomFilters.java:L130-L156] — again a main-driven demonstration of add/check methods on a Bloom filter.
• [src/main/java/com/crossoverjie/proxy/jdk/impl/ISubjectImpl.java:L1-L13] — a small proxy pattern example implementing an interface (ISubject).

So the "API" style in jcsprout is: small, independent classes, often with a main for direct execution, minimal formal contracts, and no versioning/compatibility guarantees. It's meant to be read and run, not integrated as a dependency.

joda-time, by contrast, is a real library with a deliberate, carefully documented public API built around interfaces and abstract base classes:

• ReadableInstant [src/main/java/org/joda/time/ReadableInstant.java:L1-L37] — defines a read-only view of an instant in time (millis since epoch), explicitly documented as the recommended parameter type for methods that only need to read a datetime.
• ReadableDuration [src/main/java/org/joda/time/ReadableDuration.java:L1-L38] — read-only duration contract, with explicit null-handling semantics ("treat null as a zero length duration").
• ReadableDateTime [src/main/java/org/joda/time/ReadableDateTime.java:L1-L33] and ReadablePartial [src/main/java/org/joda/time/ReadablePartial.java:L1-L37] — layered abstractions distinguishing full instants from partial (local) time representations.
• DateTimeComparator [src/main/java/org/joda/time/DateTimeComparator.java:L1-L47, L248-L285] — a thread-safe, immutable comparator with well-defined equals/hashCode/toString contracts.
• AbstractPeriod [src/main/java/org/joda/time/base/AbstractPeriod.java:L79-L118] — shared implementation logic (getValues, get(DurationFieldType)) that concrete period classes build on.

Key API-design differences:

1. Stability and intent: joda-time's classes carry explicit @since tags, binary-compatibility notes (e.g., the compareTo contract note in [ReadableInstant.java:L27-L30] and [ReadableDuration.java:L24-L27]), and documented thread-safety/immutability guarantees (e.g., DateTimeComparator is "thread-safe and immutable" per its Javadoc). jcsprout classes generally don't document such guarantees.
2. Abstraction layering: joda-time separates "Readable" interfaces (read-only contracts) from mutable/abstract base implementations, encouraging consumers to code against interfaces like ReadableInstant rather than concrete classes. jcsprout mostly uses concrete classes directly with no interface-based contract layer (aside from small examples like the proxy pattern demo).
3. Extensibility hooks: joda-time has pluggable provider mechanisms, e.g., DateTimeZone.getDefaultProvider() supports multiple configuration strategies (system property, filesystem folder, classpath, fallback) [src/main/java/org/joda/time/DateTimeZone.java:L515-L554]. jcsprout has no equivalent extensibility model — its "configuration" is just h