How do their APIs compare?

API comparison: jakewharton/butterknife vs json-path/jsonpath

These two libraries solve very different problems, so their APIs reflect fundamentally different design goals: butterknife is an annotation-processing/codegen library for Android view binding, while jsonpath is a query/extraction library for JSON documents.

Entry points and usage style

butterknife exposes a small runtime API backed by generated code. The primary entry point is the ButterKnife class, whose bind-family methods locate a generated _ViewBinding class for the target's runtime type via reflection-based class loading, walking up the superclass chain until it either finds a match or hits a framework class (android., java., androidx.) and gives up:

Class<?> bindingClass = cls.getClassLoader().loadClass(clsName + "_ViewBinding");
...
if (debug) Log.d(TAG, "MISS: Reached framework class. Abandoning search.");

[butterknife/src/main/java/butterknife/ButterKnife.java:L194-L215]

The actual "API" that developers touch day-to-day is mostly annotations (@BindView, @OnClick, @BindString, etc., per the README), not method calls — the heavy lifting happens at compile time in butterknife-compiler, which generates a ViewBinding constructor per annotated class. That generated constructor logic — handling parent bindings, target fields, suppressing lint warnings for resource/touch bindings — is built up programmatically in BindingSet.java [butterknife-compiler/src/main/java/butterknife/compiler/BindingSet.java:L202-L241].

jsonpath, by contrast, is a fluent, functional-style Java API centered on JsonPath and ParseContext. You either compile a reusable path object (JsonPath.compile("$.store.book[1]")) or do a one-shot static read (JsonPath.read(json, "...")), as documented directly in the class Javadoc [json-path/src/main/java/com/jayway/jsonpath/JsonPath.java:L1-L90]. ParseContext [json-path/src/main/java/com/jayway/jsonpath/ParseContext.java:L1-L25] provides the parsing side (from String, File, InputStream, URL), separate from path evaluation.

Type handling

• butterknife's "typing" concerns are about matching Android view/listener method signatures at compile time — e.g. the compiler's parameter-matching logic in ButterKnifeProcessor builds descriptive error messages when annotated method parameters don't match any listener callback parameter [butterknife-compiler/src/main/java/butterknife/compiler/ButterKnifeProcessor.java:L1174-L1213].
• jsonpath instead offers TypeRef<T>, a generics-preserving helper class used with ReadContext so callers can request strongly-typed results like List<Integer> despite Java type erasure [json-path/src/main/java/com/jayway/jsonpath/TypeRef.java:L1-L29]. There's no equivalent concept in butterknife, since it binds to concrete Android types resolved at annotation-processing time rather than runtime generics.

Assertion/matcher surface

jsonpath additionally ships a separate json-path-assert module with a Hamcrest-based matcher API — JsonPathMatchers.hasJsonPath(...), withJsonPath(...), isJson(...) — designed for test assertions against JSON documents [json-path-assert/src/main/java/com/jayway/jsonpath/matchers/JsonPathMatchers.java:L14-L76]. butterknife has no analogous testing/assertion API; its closest "auxiliary" module is butterknife-lint, which provides static-analysis Detectors (e.g. InvalidR2UsageDetector) rather than runtime assertions [butterknife-lint/src/main/java/butterknife/lint/InvalidR2UsageDetector.java:L28-L113].

Summary of the contrast

Aspect	butterknife	jsonpath
Primary interaction	Annotations + generated code	Fluent method calls (JsonPath, ReadContext)
Core "compile" step	Annotation processor generates _ViewBinding classes	JsonPath.compile(...) builds a re