How do their APIs compare?

Comparing "APIs" across these two repos isn't quite apples-to-apples, since they serve very different purposes — one is a personal Java learning/reference repo with runnable demo classes, the other is a library with a real public API for consumers. Let me lay out what's actually visible in the data.

crossoverjie/jcsprout: no real public API, just standalone demo classes

jcsprout isn't a library — it's a collection of independent main()-driven Java classes illustrating concepts (collections, threading, algorithms, JVM, etc.). There's no cohesive API surface meant for external consumption. For example:

• Search.java exposes a static search(String keyWord) method used only within its own main for demonstrating a wildcard/trie-like search over a map [src/main/java/com/crossoverjie/actual/Search.java:L141-L158], with test-style assertions run inline in main rather than via a real test framework [src/main/java/com/crossoverjie/actual/Search.java:L79-L118].
• LRUAbstractMap.java documents (in comments) an intended API — lruCallback(K key, V value) and timeoutCallback(K key, V value) callbacks for an LRU cache with size and timeout eviction — but this is a self-contained teaching implementation, not something other modules depend on [src/main/java/com/crossoverjie/actual/LRUAbstractMap.java:L1-L26].
• HashMapTest.java, ThreadCommunication.java, CacheLoaderTest.java, CollectionsTest.java (this one using JMH benchmark annotations) are similarly isolated demo/benchmark classes with main methods, not reusable APIs [src/main/java/com/crossoverjie/basic/HashMapTest.java:L15-L43] [src/main/java/com/crossoverjie/actual/ThreadCommunication.java:L1-L17] [src/main/java/com/crossoverjie/basic/CollectionsTest.java:L1-L22].

So there's no versioned contract, no consumer-facing interface design — each file is a self-contained example.

json-path/jsonpath: a deliberate, fluent, consumer-facing API

jsonpath is a library designed to be embedded in other applications, and its API reflects that:

• Entry point / fluent reads: JsonPath.using(configuration).parse(json).read(path, ...) chains configuration, parsing, and path evaluation, with automatic type-casting attempts on read results [README.md:L201-L217].
• Predicate/filter DSL: Criteria.where(...).is(...).and(...) combined with Filter.filter(...), supporting relational operators like regex, in, and boolean composition (or/and) of filters — a small embedded query language [json-path/src/main/java/com/jayway/jsonpath/Criteria.java:L199-L238] [README.md:L274-L310].
• Type-safety helper: TypeRef<T> is an abstract class users subclass anonymously to preserve generic type info for mapping results (a common pattern to defeat type erasure) [json-path/src/main/java/com/jayway/jsonpath/TypeRef.java:L30-L55].
• Separate assertion API module (json-path-assert): JsonAsserter provides a fluent with(json).assertThat(path, matcher).and()... chain built on Hamcrest Matchers, including assertEquals, assertNull, assertNotDefined [json-path-assert/src/main/java/com/jayway/jsonassert/JsonAsserter.java:L5-L91]. JsonPathMatchers layers Hamcrest matchers like hasJsonPath/hasNoJsonPath on top of that for use in test assertions [json-path-assert/src/main/java/com/jayway/jsonpath/matchers/JsonPathMatchers.java:L14-L76].
• Extensible mapping: the API supports pluggable MappingProviders (Jackson, Jackson3, Gson, Jakarta) so .read(path, SomeType.class) can deserialize into arbitrary types [README.md:L201-L240].

Summary of the contrast

• Design intent: jcsprout's code is pedagogical and disposable per-class; jsonpath's code is a stable, documented, fluent API meant for long-term external use.
• Consistency: js