How do their APIs compare?

These two projects have fundamentally different purposes, so their "APIs" aren't really comparable in style, but here's a concrete breakdown of what each exposes and how:

jakewharton/butterknife — annotation-driven binding API

Butter Knife's public surface is almost entirely annotations + a static facade class, not something you call imperatively for logic. Two flavors exist:

• Annotations declared in butterknife-annotations, e.g. @BindView, @BindBitmap, @OnClick, @OnTouch, @OnPageChange, @OnItemLongClick. Each listener annotation is backed by a @ListenerClass/@ListenerMethod meta-annotation describing the setter/remover and callback signature to generate, e.g. OnTouch wires to View.OnTouchListener#onTouch [butterknife-annotations/src/main/java/butterknife/OnTouch.java:L29-L47], and OnPageChange wires to ViewPager.OnPageChangeListener [butterknife-annotations/src/main/java/butterknife/OnPageChange.java:L29-L37].
• The ButterKnife class is the single entry point, and it's intentionally non-instantiable (private ButterKnife() { throw new AssertionError(...); } [butterknife/src/main/java/butterknife/ButterKnife.java:L74-L77]). Its API is a family of overloaded static bind(...) methods:
  • bind(Activity), bind(View), bind(Object target, View source), plus variants taking Dialog/Activity as the source for lookups [butterknife/src/main/java/butterknife/ButterKnife.java:L91-L113, L154-L159].
  • All return an Unbinder, letting callers later release view references (important in Fragment/ViewHolder lifecycles).
  • There's also setDebug(boolean) for verbose logging [butterknife/src/main/java/butterknife/ButterKnife.java:L85-L87].
• Two interchangeable runtime implementations exist behind the same ButterKnife API: the normal butterknife artifact resolves to annotation-processor-generated _ViewBinding classes via a cached constructor lookup [butterknife/src/main/java/butterknife/ButterKnife.java:L184-L193], while butterknife-reflect implements the identical bind method signatures but resolves bindings by walking getDeclaredFields()/methods reflectively at runtime instead of using generated code [butterknife-reflect/src/main/java/butterknife/ButterKnife.java:L129-L168]. This is a deliberate binary-compatible dual-implementation design, documented as an IDE-build-speed tradeoff.
• The API is heavily annotated with nullability/thread-safety contracts (@NonNull, @UiThread, @CheckResult), which is idiomatic for a library meant to be called from arbitrary Android app code.

pqpo/smartcropper

I don't have direct visibility into smartcropper's own Java API surface (its SmartCropper class, crop/detect methods, etc.) from the retrieved chunks — everything surfaced for this repo so far is vendored OpenCV C++ header code (smartcropperlib/opencv/include/...), e.g. CUDA functional/comparison templates [smartcropperlib/opencv/include/opencv2/core/cuda/functional.hpp:L141-L215], saturate_cast specializations [smartcropperlib/opencv/include/opencv2/core/cuda/saturate_cast.hpp:L106-L215], and core/check.hpp diagnostics [smartcropperlib/opencv/include/opencv2/core/check.hpp:L1-L40]. That's third-party OpenCV internals bundled into the project, not smartcropper's own public API.

Bottom line on comparison:

• Butter Knife's API is a small, well-documented static Java facade + annotation set aimed at eliminating boilerplate view lookups — a classic "declarative binding" API.
• Smartcropper, based on what's retrieved, is primarily consuming a native/C++ OpenCV computer-vision library under the hood; its own Java-facing API (likely something like a SmartCropper utility class with crop/detect static methods, based on the project's stated purpose of image c