If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/JakeWharton/butterknife shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across all four use cases

• 17 active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 3y ago
• ⚠ Concentrated ownership — top contributor handles 75% of recent commits

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live JakeWharton/butterknife repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/JakeWharton/butterknife.

What it runs against: a local clone of JakeWharton/butterknife — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in JakeWharton/butterknife | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 1009 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of JakeWharton/butterknife. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/JakeWharton/butterknife.git
#   cd butterknife
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of JakeWharton/butterknife and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "JakeWharton/butterknife(\\.git)?\\b" \\
  && ok "origin remote is JakeWharton/butterknife" \\
  || miss "origin remote is not JakeWharton/butterknife (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "butterknife-compiler/src/main/java/butterknife/compiler/ButterKnifeProcessor.java" \\
  && ok "butterknife-compiler/src/main/java/butterknife/compiler/ButterKnifeProcessor.java" \\
  || miss "missing critical file: butterknife-compiler/src/main/java/butterknife/compiler/ButterKnifeProcessor.java"
test -f "butterknife-compiler/src/main/java/butterknife/compiler/BindingSet.java" \\
  && ok "butterknife-compiler/src/main/java/butterknife/compiler/BindingSet.java" \\
  || miss "missing critical file: butterknife-compiler/src/main/java/butterknife/compiler/BindingSet.java"
test -f "butterknife-annotations/src/main/java/butterknife/BindView.java" \\
  && ok "butterknife-annotations/src/main/java/butterknife/BindView.java" \\
  || miss "missing critical file: butterknife-annotations/src/main/java/butterknife/BindView.java"
test -f "butterknife-compiler/src/main/java/butterknife/compiler/FieldViewBinding.java" \\
  && ok "butterknife-compiler/src/main/java/butterknife/compiler/FieldViewBinding.java" \\
  || miss "missing critical file: butterknife-compiler/src/main/java/butterknife/compiler/FieldViewBinding.java"
test -f "butterknife-compiler/src/main/java/butterknife/compiler/MethodViewBinding.java" \\
  && ok "butterknife-compiler/src/main/java/butterknife/compiler/MethodViewBinding.java" \\
  || miss "missing critical file: butterknife-compiler/src/main/java/butterknife/compiler/MethodViewBinding.java"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 1009 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~979d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/JakeWharton/butterknife"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Butter Knife is an annotation processing library that generates Android view-binding boilerplate code at compile-time, eliminating manual findViewById() calls and verbose listener setup. It uses Java annotations like @BindView, @OnClick, and resource annotations (@BindString, @BindColor, etc.) to declaratively bind Android views and callbacks to fields and methods. Multi-module Gradle project: butterknife-annotations/ contains annotation definitions (@BindView, @OnClick, etc.) and internal metadata (ListenerClass.java, ListenerMethod.java); butterknife-compiler/ contains the annotation processor (ButterKnifeProcessor.java) and code generators (BindingSet.java, FieldAnimationBinding.java, etc.); butterknife-gradle-plugin/ provides library project support with R2 resource handling.

Android developers building traditional View-based applications who want to reduce boilerplate and improve code readability. Maintainers of Android libraries who need view binding with R2 resource support for library projects.

Butter Knife is stable and widely adopted (546KB Java codebase, multi-year history) but officially deprecated as of the README. The project is in maintenance mode: the maintainer now recommends switching to Android's official View Binding. Existing versions work reliably, but only critical AGP integration fixes are considered; no new features or general bug fixes.

High deprecation risk: the maintainer explicitly directs users to View Binding instead. Single maintainer (Jake Wharton) with no recent activity visible in the provided data. The project is stable for existing users but represents tech debt for new projects. Android tooling evolution (AGP updates) may introduce compatibility issues that won't be fixed.

The project is in maintenance mode. No active feature development visible in the file structure. CI is configured via .travis.yml and .github/workflows/gradle-wrapper-validation.yml. The CHANGELOG.md and RELEASING.md suggest a structured release process, but current activity level is not visible from the provided snapshot.

git clone https://github.com/JakeWharton/butterknife.git
cd butterknife
./gradlew build
./gradlew test

Daily commands: This is not a runnable application—it's a library and toolchain. To test the annotation processor: ./gradlew butterknife-compiler:test. To use in a sample app, see the integration: add implementation 'com.jakewharton:butterknife:10.2.3' and annotationProcessor 'com.jakewharton:butterknife-compiler:10.2.3' to an Android app's build.gradle, then annotate fields and run ./gradlew assembleDebug.

• butterknife-compiler/src/main/java/butterknife/compiler/ButterKnifeProcessor.java — Main annotation processor entry point that orchestrates the entire compilation and code generation pipeline; fundamental to understanding how annotations are processed.
• butterknife-compiler/src/main/java/butterknife/compiler/BindingSet.java — Core abstraction that generates the boilerplate binding code for a single class; contains the logic for creating ViewBinding classes and resource accessors.
• butterknife-annotations/src/main/java/butterknife/BindView.java — Primary annotation for view binding; defines the core API that users interact with and that the processor must handle.
• butterknife-compiler/src/main/java/butterknife/compiler/FieldViewBinding.java — Handles generation of field binding code for views; critical for understanding how individual view bindings are materialized.
• butterknife-compiler/src/main/java/butterknife/compiler/MethodViewBinding.java — Processes listener method bindings (e.g., @OnClick); essential for understanding how callbacks and event handlers are wired.
• butterknife-gradle-plugin/src/main/java/butterknife/plugin/R2Generator.kt — Gradle plugin that generates R2 class for resource ID stability; critical for integration with AGP and resource binding.

Add a new view binding annotation

1. Create a new annotation interface in butterknife-annotations (e.g., @BindCustomView.java) that targets FIELD or METHOD (butterknife-annotations/src/main/java/butterknife/BindCustomView.java)
2. Add metadata using @ListenerClass and @ListenerMethod if it's a callback annotation, or simple @Retention(RUNTIME) if it's a resource binding (butterknife-annotations/src/main/java/butterknife/internal/ListenerClass.java)
3. Create a corresponding binding class in the compiler (e.g., FieldCustomBinding.java extending FieldViewBinding) to generate code (butterknife-compiler/src/main/java/butterknife/compiler/FieldCustomBinding.java)
4. Register the annotation handler in ButterKnifeProcessor.process() method to route the annotation to your binding class (butterknife-compiler/src/main/java/butterknife/compiler/ButterKnifeProcessor.java)
5. Add unit tests in BindingSetTest.java to verify code generation for various scenarios (butterknife-compiler/src/test/java/butterknife/compiler/BindingSetTest.java)

Add a new resource binding annotation (e.g., @BindCustomResource)

1. Create annotation in butterknife-annotations/src/main/java/butterknife/BindCustomResource.java with @Retention(RUNTIME) (butterknife-annotations/src/main/java/butterknife/BindCustomResource.java)
2. Create a binding class extending ResourceBinding in the compiler (e.g., FieldCustomResourceBinding.java) (butterknife-compiler/src/main/java/butterknife/compiler/FieldCustomResourceBinding.java)
3. Override generateCode() method to emit the resource lookup and casting logic using JavaPoet (butterknife-compiler/src/main/java/butterknife/compiler/ResourceBinding.java)
4. Register handler in ButterKnifeProcessor to detect @BindCustomResource and instantiate your binding class (butterknife-compiler/src/main/java/butterknife/compiler/ButterKnifeProcessor.java)

Add support for a new listener event (e.g., @OnCustomEvent)

1. Create @OnCustomEvent annotation with @ListenerClass metadata pointing to the listener interface (butterknife-annotations/src/main/java/butterknife/OnCustomEvent.java)
2. Add @ListenerMethod annotation inside @ListenerClass to define the callback method signature and ID mapping (butterknife-annotations/src/main/java/butterknife/internal/ListenerClass.java)
3. Create MethodCustomEventBinding class extending MethodViewBinding to generate listener registration code (butterknife-compiler/src/main/java/butterknife/compiler/MethodCustomEventBinding.java)
4. Update ButterKnifeProcessor to recognize @OnCustomEvent and route to your binding handler (butterknife-compiler/src/main/java/butterknife/compiler/ButterKnifeProcessor.java)

• Annotation Processing (APT) — Compile-time code generation eliminates runtime reflection overhead and enables compile-time safety checking; core to ButterKnife's zero-runtime-cost philosophy.
• JavaPoet — Programmatic Java source code generation with type-safe API; avoids string concatenation errors and handles complex code structure generation reliably.
• Gradle Plugin (Kotlin DSL) — Integrates with Android build system to generate R2 resources for stable resource ID references across AGP versions; decouples resource IDs from generated bindings.
• android-apt / KAPT — Bridges Gradle build system with Java annotation processing to route generated code into compilation classpath automatically.

• Compile-time code generation vs. reflection-based binding

  • Why: Performance and static safety; code generation adds build-time overhead but eliminates runtime reflection costs and provides compile-time error detection.
  • Consequence: Build times increase slightly; developers see generated code which aids debugging but adds verbosity to project structure.

• R2 generation via Gradle plugin

  • Why: Provides stable resource IDs independent of AGP's R class generation; allows safe resource references in generated code across different build flavors and AGP versions.
  • Consequence: Additional Gradle plugin dependency and build step; requires integration with resource pipeline.

• Annotation-based API (vs. XML configuration)

  • Why: Co-locates binding declaration with field/method definition; leverages type-safety and IDE support for annotations.
  • Consequence: Requires APT setup; less suitable for non-Java languages or dynamic scenarios.

• Runtime data binding or observable properties (static code generation only)
• Two-way data synchronization or reactive streams
• Support for Kotlin synthetic imports (requires explicit @BindView annotations)
• Dynamic view creation or view pool recycling
• Proguard/R8 rule generation (users must configure rules manually)

Java 8 requirement: Compiler and library require compileOptions { sourceCompatibility JavaVersion.VERSION_1_8 } in app's build.gradle or compilation will fail. Library projects: Must use R2 (from gradle plugin) instead of R in annotations, or binding will reference wrong resources. Annotation processing: Requires annotationProcessor (Java) or kapt (Kotlin) in dependencies; missing it causes no errors but silently generates no code. AGP compatibility: Very old projects on AGP < 3.3.0 may face issues; newer AGP versions may break this deprecated tool without fixes. Incap optimization: Uses incap library to optimize annotation processor invocations; disable or troubleshoot if incremental compilation acts unexpectedly.

• Annotation Processing (APT) — Butter Knife's entire mechanism relies on compile-time annotation processing via javax.annotation.processing.AbstractProcessor to generate code without runtime reflection
• Code Generation with JavaPoet — The library generates Java method bodies (e.g., bind() methods) programmatically; understanding JavaPoet's API is essential to modifying BindingSet.java
• Resource Indirection (R vs. R2) — Library projects must use R2 to avoid resource ID resolution conflicts; Butter Knife's gradle plugin provides this indirection layer
• Listener Interface Reflection (ListenerClass/ListenerMethod) — Butter Knife analyzes listener interfaces at compile-time to auto-generate callback adapters for @OnClick, @OnItemSelected, etc. without manual inner classes
• Incremental Annotation Processing (INCAP) — Butter Knife uses the INCAP library to declare which annotations it handles, allowing Gradle to optimize incremental builds and avoid reprocessing unchanged files
• Android View Binding (Successor Technology) — Official replacement for Butter Knife; understanding the shift from annotation processing to generated Kotlin synthetic accessors helps understand Butter Knife's limitations

• google/auto — Provides Auto Service and Auto Common libraries used by Butter Knife for annotation processor registration and utilities
• square/javapoet — Code generation library that Butter Knife uses to emit Java source files for view binding at compile-time
• androidannotations/androidannotations — Alternative annotation-based Android binding library; comparable approach to eliminating boilerplate via compile-time code generation
• immutables/immutables — Another annotation processing example in the Java ecosystem; shows mature patterns for processor implementation and testing
• google/dagger — Dependency injection library; Butter Knife is positioned as a lighter-weight, view-focused sibling (as stated in the README: 'infinitely less sharp')

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive test coverage for butterknife-compiler code generation

The butterknife-compiler/src/test/java directory only contains BindingSetTest.java. Given that this is an annotation processor that generates boilerplate code, there should be extensive tests for each binding type (FieldViewBinding, MethodViewBinding, FieldResourceBinding, FieldAnimationBinding, etc.). This is critical because code generation bugs directly impact all users. New contributors can add unit tests for specific binding classes using the existing compile-testing framework already included in dependencies.

• [ ] Create butterknife-compiler/src/test/java/butterknife/compiler/FieldViewBindingTest.java with tests for view binding code generation
• [ ] Create butterknife-compiler/src/test/java/butterknife/compiler/MethodViewBindingTest.java testing listener binding generation
• [ ] Create butterknife-compiler/src/test/java/butterknife/compiler/ResourceBindingTest.java testing @BindString, @BindColor, @BindDimen code generation
• [ ] Create butterknife-compiler/src/test/java/butterknife/compiler/FieldCollectionViewBindingTest.java testing @BindViews functionality
• [ ] Use com.google.testing.compile:compile-testing:0.15 (already in dependencies) to validate generated Java source code

Add GitHub Actions workflow for automated testing on pull requests

The repository has .github/workflows/gradle-wrapper-validation.yml but is missing a comprehensive CI workflow for running tests and builds. The .travis.yml exists but GitHub Actions is now the standard. This is valuable for catching regressions early and providing feedback to contributors without relying on external CI services.

• [ ] Create .github/workflows/tests.yml that runs './gradlew build' on push and PR for main branches
• [ ] Include matrix testing for multiple JDK versions (11, 17) since annotation processors are JDK-sensitive
• [ ] Run tests for all modules: butterknife-annotations, butterknife-compiler, butterknife-gradle-plugin
• [ ] Add status badge to README.md pointing to the workflow

Add integration tests for butterknife-gradle-plugin against sample Android projects

The butterknife-gradle-plugin/src/main directory exists but there are no visible test files in the structure. The gradle plugin is critical infrastructure that must work with various AGP versions (the README mentions 'integration with AGP'). Integration tests validating the plugin works with real Android projects would catch compatibility issues early.

• [ ] Create butterknife-gradle-plugin/src/test/java/butterknife/gradle/ directory structure
• [ ] Create butterknife-gradle-plugin/src/test/resources/ with minimal sample Android project structures
• [ ] Write functional tests that apply the plugin and verify generated bytecode/classes are correct
• [ ] Test against minSdk 14 and compileSdk 28 versions specified in build.gradle versions.ext
• [ ] Document in RELEASING.md any manual testing steps that could be automated

• Add unit tests for FieldAnimationBinding.java and FieldCollectionViewBinding.java in butterknife-compiler/src/test/ using compile-testing (tests are sparse in the compiler module)
• Document resource binding examples for @BindString, @BindColor, @BindDimen in README.md with actual code snippets, as they are defined but minimally documented
• Create a migration guide in CHANGELOG.md or a new MIGRATION.md showing how to convert Butter Knife code to AndroidX View Binding, given the deprecation notice

• High · Outdated Android Gradle Plugin — build.gradle - deps.android.gradlePlugin. The project uses com.android.tools.build:gradle:3.3.0, which is significantly outdated (released in 2019). This version likely contains known security vulnerabilities and misses critical security patches from Android toolchain. Fix: Update to the latest stable version of Android Gradle Plugin (currently 8.x or higher). Review release notes for breaking changes.
• High · Outdated Kotlin Version — build.gradle - versions.kotlin. Kotlin version 1.2.71 is severely outdated (released in 2018). This version may contain unpatched security vulnerabilities in the Kotlin compiler and standard library. Fix: Update to Kotlin 1.9.x or later. Test compatibility with updated Android Gradle Plugin and other dependencies.
• High · Outdated Lint Dependencies — build.gradle - deps.lint (all versions). Lint dependencies (26.2.0) are pinned to Android Tools version from 2018, which is severely outdated and may lack security fixes for code analysis and build process vulnerabilities. Fix: Update androidTools version to match the current Android Gradle Plugin version (8.x+), which automatically updates lint dependencies.
• High · Outdated Guava Dependency — build.gradle - deps.guava. Guava 24.0-jre was released in 2018 and may contain known vulnerabilities. Several security issues have been addressed in later versions. Fix: Update Guava to version 31.1-jre or higher, with careful testing for compatibility.
• Medium · Outdated AndroidX Dependencies — build.gradle - deps.androidx. AndroidX libraries (core:1.0.0, viewpager:1.0.0, annotation:1.0.0, test runner:1.1.0) are from 2019 and may lack security patches. The viewpager v1 is especially outdated. Fix: Update to latest stable versions: androidx.core:core:1.12.x, androidx.viewpager:viewpager:1.0.0 (upgrade to viewpager2), androidx.annotation:annotation:1.7.x, androidx.test:runner:1.5.x
• Medium · Outdated Compile Testing Dependency — build.gradle - deps.compiletesting. com.google.testing.compile:compile-testing:0.15 is from 2018. Newer versions may include security improvements and better practices. Fix: Update to version 0.21 or higher.
• Medium · Outdated Auto Service Dependency — build.gradle - deps.auto.service. com.google.auto.service:auto-service:1.0-rc4 is a release candidate version from 2017. A stable release is now available. Fix: Update to 1.1.1 (stable release) for better stability and potential security fixes.
• Medium · Potential Insecure Deploy Script — .buildscript/deploy_snapshot.sh. The file '.buildscript/deploy_snapshot.sh' exists but content is not visible. Deployment scripts often contain hardcoded credentials or insecure practices. Fix: Review the script to ensure: 1) No hardcoded credentials, 2) Use environment variables for secrets, 3) Follow OAuth/secure token practices, 4) Ensure proper file permissions (not readable by all users).
• Low · Outdated JUnit Dependency — build.gradle - deps.junit. JUnit 4.12 is from 2014. While generally safe, newer versions provide better features and potential security improvements. Fix: Consider updating to JUnit 4.13.2 or migrating to JUnit 5 for test infrastructure modernization.
• Low · Outdated JavaPoet Dependency — undefined. JavaPoet 1.10.0 is from 2018. While the library is mature, newer versions Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.