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/evant/gradle-retrolambda 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.

WAIT — Stale — last commit 3y ago

• 14 active contributors
• Apache-2.0 licensed
• Tests present
• ⚠ Stale — last commit 3y ago
• ⚠ Single-maintainer risk — top contributor 80% of recent commits
• ⚠ No CI workflows detected

_{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 evant/gradle-retrolambda repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/evant/gradle-retrolambda.

What it runs against: a local clone of evant/gradle-retrolambda — 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 evant/gradle-retrolambda | 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 main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 1049 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of evant/gradle-retrolambda. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/evant/gradle-retrolambda.git
#   cd gradle-retrolambda
#
# 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 evant/gradle-retrolambda and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "evant/gradle-retrolambda(\\.git)?\\b" \\
  && ok "origin remote is evant/gradle-retrolambda" \\
  || miss "origin remote is not evant/gradle-retrolambda (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 main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "gradle-retrolambda/src/main/groovy/me/tatarka/RetrolambdaPlugin.groovy" \\
  && ok "gradle-retrolambda/src/main/groovy/me/tatarka/RetrolambdaPlugin.groovy" \\
  || miss "missing critical file: gradle-retrolambda/src/main/groovy/me/tatarka/RetrolambdaPlugin.groovy"
test -f "gradle-retrolambda/src/main/groovy/me/tatarka/RetrolambdaTask.groovy" \\
  && ok "gradle-retrolambda/src/main/groovy/me/tatarka/RetrolambdaTask.groovy" \\
  || miss "missing critical file: gradle-retrolambda/src/main/groovy/me/tatarka/RetrolambdaTask.groovy"
test -f "gradle-retrolambda/src/main/groovy/me/tatarka/RetrolambdaExtension.groovy" \\
  && ok "gradle-retrolambda/src/main/groovy/me/tatarka/RetrolambdaExtension.groovy" \\
  || miss "missing critical file: gradle-retrolambda/src/main/groovy/me/tatarka/RetrolambdaExtension.groovy"
test -f "gradle-retrolambda/src/main/groovy/me/tatarka/RetrolambdaExec.groovy" \\
  && ok "gradle-retrolambda/src/main/groovy/me/tatarka/RetrolambdaExec.groovy" \\
  || miss "missing critical file: gradle-retrolambda/src/main/groovy/me/tatarka/RetrolambdaExec.groovy"
test -f "gradle-retrolambda/src/main/groovy/me/tatarka/RetrolambdaUtil.groovy" \\
  && ok "gradle-retrolambda/src/main/groovy/me/tatarka/RetrolambdaUtil.groovy" \\
  || miss "missing critical file: gradle-retrolambda/src/main/groovy/me/tatarka/RetrolambdaUtil.groovy"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 1049 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1019d)"
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/evant/gradle-retrolambda"
  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).

gradle-retrolambda is a Gradle plugin that enables Java 8 lambda syntax in Java 6, 7, and Android projects by compiling with JDK8 then post-processing class files through the Retrolambda bytecode transformer. It automatically integrates with the Gradle build pipeline to desugar lambda expressions and method references into Java 5-compatible bytecode, letting developers write modern Java while targeting older runtimes. Single-module Gradle plugin structure: gradle-retrolambda/ contains the core plugin code in src/main/groovy/ with platform-specific implementations (RetrolambdaPluginJava.groovy, RetrolambdaPluginAndroid.groovy, RetrolambdaPluginGroovy.groovy), a shared RetrolambdaTask.groovy executor, RetrolambdaExtension.groovy for configuration, and RetrolambdaTransform.groovy for Android Transform API integration. Tests in src/test/java/ verify behavior across Android variants and Java/Groovy plugins. A sample-android-app/ demonstrates real-world usage.

Android developers and Java developers stuck on Java 6/7 runtimes who want to use Java 8 lambda syntax without upgrading their entire target platform. Also used by library maintainers who need to support older Android API levels while using modern language features.

This project appears mature but showing signs of age. It has Maven Central publication (3.7.1 release visible in README), a structured test suite across multiple Android plugin versions (AndroidAppPluginTest.java, AndroidLibPluginTest.java, etc.), and organized sample apps. However, the repo's maintenance status is not clearly visible from the file listing alone; Java 8+ removed the need for this plugin (modern Android now targets Java 8+ natively), so active development may have slowed significantly.

This plugin depends on the external Retrolambda project (net.orfjackal.retrolambda:retrolambda:2.5.6 by default), creating a single external dependency risk. The Android ecosystem has largely moved past this tool—Android Gradle Plugin 4.1+ added native desugaring support, making this plugin obsolete for modern projects. Minimal version constraints are mentioned (Android plugin 1.5.0+, Gradle 2.5+), but these are very old baselines that may introduce compatibility issues with current tooling.

Unable to determine from file listing alone. The presence of CHANGELOG.md suggests versioning history exists, but no recent commit dates or open PR/issue counts are visible in the provided data. The plugin is likely in maintenance mode rather than active feature development.

Clone and build: git clone https://github.com/evant/gradle-retrolambda.git && cd gradle-retrolambda && ./gradlew build. The Gradle wrapper (gradlew/gradlew.bat) is included. Run tests with ./gradlew test. Inspect gradle.properties for version metadata.

Daily commands: This is a build tool, not an application. To use it: apply the plugin in a build.gradle (apply plugin: 'me.tatarka.retrolambda'), set JDK8 as default, then run ./gradlew build. To develop on the plugin itself: ./gradlew build compiles and tests the plugin; ./gradlew install publishes to local Maven repo for testing in sample projects.

• gradle-retrolambda/src/main/groovy/me/tatarka/RetrolambdaPlugin.groovy — Main plugin entry point that orchestrates the retrolambda transformation pipeline for all project types.
• gradle-retrolambda/src/main/groovy/me/tatarka/RetrolambdaTask.groovy — Core task definition that executes the retrolambda Java bytecode transformation process.
• gradle-retrolambda/src/main/groovy/me/tatarka/RetrolambdaExtension.groovy — Configuration extension that exposes retrolambda options to build.gradle files; essential for user customization.
• gradle-retrolambda/src/main/groovy/me/tatarka/RetrolambdaExec.groovy — Executes the retrolambda command-line tool with proper JVM and classpath configuration.
• gradle-retrolambda/src/main/groovy/me/tatarka/RetrolambdaUtil.groovy — Utility functions for Java version detection, classpath resolution, and cross-version compatibility.
• gradle-retrolambda/src/main/groovy/me/tatarka/RetrolambdaTransform.groovy — Android Gradle transform API integration for bytecode post-processing in the build pipeline.

Add lambda support to a Java project

1. Apply the retrolambda plugin in build.gradle after the java plugin (gradle-retrolambda/src/main/groovy/me/tatarka/RetrolambdaPluginJava.groovy)
2. Configure target Java version via retrolambda extension block (e.g., retrolambda { javaVersion JavaVersion.VERSION_1_7 }) (gradle-retrolambda/src/main/groovy/me/tatarka/RetrolambdaExtension.groovy)
3. Ensure JDK8 is set as JAVA_HOME; the plugin will compile with JDK8 then retrofy bytecode (gradle-retrolambda/src/main/groovy/me/tatarka/RetrolambdaUtil.groovy)

Add lambda support to an Android project

1. Apply the retrolambda plugin after the android plugin in build.gradle (gradle-retrolambda/src/main/groovy/me/tatarka/RetrolambdaPluginAndroid.groovy)
2. The plugin automatically registers a Transform for each build variant to intercept compiled classes (gradle-retrolambda/src/main/groovy/me/tatarka/RetrolambdaTransform.groovy)
3. Configure retrolambda options in the retrolambda block if needed (e.g., includeMainClasses, excludeClasses) (gradle-retrolambda/src/main/groovy/me/tatarka/RetrolambdaExtension.groovy)

Customize retrolambda transformation behavior

1. Use the retrolambda extension block in build.gradle to set javaVersion, includeMainClasses, excludeClasses, or enabled properties (gradle-retrolambda/src/main/groovy/me/tatarka/RetrolambdaExtension.groovy)
2. For advanced configuration, examine RetrolambdaTask to understand task inputs (source/target class directories) and outputs (gradle-retrolambda/src/main/groovy/me/tatarka/RetrolambdaTask.groovy)
3. Use RetrolambdaUtil methods to validate Java version compatibility and debug classpath issues (gradle-retrolambda/src/main/groovy/me/tatarka/RetrolambdaUtil.groovy)

• Groovy — Gradle plugin development standard; provides dynamic DSL and metaprogramming for flexible plugin configuration.
• Gradle Plugin API — Required for integrating into Gradle's build lifecycle; enables task registration, variant configuration, and transform hooks.
• Retrolambda (external CLI tool) — Core bytecode transformation engine; converts Java 8 lambda syntax to Java 6/7 compatible synthetic classes without source recompilation.
• Android Gradle Transform API — Allows post-compilation bytecode transformation in Android build pipeline without modifying source or breaking incremental builds.

• Delegate bytecode transformation to external retrolambda CLI tool rather than implement inline

  • Why: Retrolambda is mature, well-tested, and independently maintained; avoids duplicating complex bytecode manipulation logic.
  • Consequence: Adds process spawning overhead and dependency on external tool availability; simplifies maintenance and reduces plugin complexity.

• Use Gradle Transform API for Android instead of task-based approach

  • Why: Transform API integrates cleanly with Android's incremental compilation and build variant system.
  • Consequence: Requires Android Gradle plugin 1.5.0+; not compatible with older Android build systems.

• Require JDK8 as JAVA_HOME for compilation, then retrofy to lower targets

  • Why: Simplifies lambda parsing and compilation; retrolambda's downconversion is proven and reliable.
  • Consequence: Users must have JDK8 installed even if targeting Java 6/7; cannot use lower JDK versions for source builds.

• Does not provide runtime lambda support for Java 6/7; only enables compilation with lambda syntax via bytecode transformation.
• Does not modify Gradle core or other plugins; operates as a standalone plugin applied to projects.
• Does not handle complex reactive/streaming libraries (e.g., RxJava) beyond basic lambda compatibility.
• Not designed for real-time incremental compilation; relies on Gradle's caching and variant-level transformation.

JDK8 must be the default Java version when building (not just in PATH); the plugin invokes the default Java compiler to compile source to Java 8 bytecode before retrolambda processes it. Android projects must use Android Gradle Plugin 1.5.0+; older versions lack Transform API support. The incremental flag defaults to true but disables automatically if defaultMethods is enabled (documented in README but easy to miss when debugging slow builds). Retrolambda dependency is fetched from Maven Central; offline builds will fail unless pre-downloaded.

• Java bytecode desugaring — This entire plugin exists to desugar Java 8 syntax (lambdas, method references, default interface methods) into bytecode that older JVMs understand; understanding what desugaring means and why it's necessary is fundamental to using this tool
• Java invokedynamic instruction — Java 8 lambdas compile using invokedynamic bytecode instructions; Retrolambda converts these into synthetic inner classes for Java 5 compatibility, and the plugin manages this conversion in the build pipeline
• Gradle Transform API — RetrolambdaTransform.groovy uses the Android Gradle Plugin's Transform API to inject retrolambda into the compilation-to-packaging pipeline; understanding transforms is required to debug Android integration issues
• Gradle plugin configuration DSL — RetrolambdaExtension.groovy defines a Gradle extension block allowing users to configure javaVersion, jvmArgs, and feature flags; understanding Gradle's extension mechanism is needed to modify or extend plugin options
• Incremental compilation and task caching — The plugin supports incremental mode (retrolambda only processes changed class files) vs. full reprocessing; understanding this tradeoff is important for performance tuning in large projects and explains why defaultMethods disables incremental mode
• Method references and functional interfaces — The plugin handles not just lambda expressions but also method references (e.g., String::valueOf); understanding Java's functional interface contract helps predict which constructs Retrolambda can successfully transform
• Android build variant filtering — RetrolambdaPluginAndroid.groovy uses include/exclude configurations to selectively apply retrolambda to specific build variants (Debug, Release, Test); understanding Android variant model is needed to configure the plugin correctly for multi-variant projects

• orfjackal/retrolambda — The core bytecode transformation library that gradle-retrolambda wraps; this is what actually converts Java 8 lambda bytecode to Java 5-compatible form
• android/gradle-recipes — Official Android Gradle Plugin examples and patterns; useful for understanding Transform API and plugin integration patterns used by RetrolambdaTransform.groovy
• robolectric/robolectric — Android testing library frequently used alongside this plugin in projects that need Java 8 syntax on older Android targets
• square/okhttp — Real-world example of a library that historically used gradle-retrolambda to support older Android API levels while using modern Java syntax
• JakeWharton/butterknife — Another popular Android library that relied on retrolambda-style bytecode transformation to enable Java 8 features on Java 6/7 targets

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 RetrolambdaTransform.groovy

RetrolambdaTransform.groovy is a critical component that handles Gradle Transform API integration for Android, but there are no dedicated test files for it (unlike RetrolambdaTask.groovy which has indirect coverage). This is a high-value missing test because Transform API integration is complex and Android-specific, making it prone to regressions across Gradle/Android plugin versions.

• [ ] Create gradle-retrolambda/src/test/java/me/tatarka/RetrolambdaTransformTest.java
• [ ] Add tests for transform execution with multiple input/output scenarios
• [ ] Add tests for jar/class file handling in the transform pipeline
• [ ] Add tests for incremental build scenarios to ensure Transform caching works correctly

Add GitHub Actions workflow for multi-version compatibility testing

The README specifies minimum versions (Gradle 2.5, Android plugin 1.5.0) but there's no CI configuration visible. New contributors should add a workflow that tests against multiple Gradle and Android plugin versions to catch compatibility regressions early. The test infrastructure exists (gradle-retrolambda/src/test/) but lacks automated CI enforcement.

• [ ] Create .github/workflows/test.yml with matrix strategy for Gradle versions (2.5, 3.x, 4.x, 5.x+)
• [ ] Add matrix strategy for Android plugin versions (1.5.0, 2.x, 3.x, 4.x+)
• [ ] Configure workflow to run './gradlew test' from both root and gradle-retrolambda subdirectories
• [ ] Add workflow status badge to README.md

Add integration tests for Groovy plugin in sample project

GroovyPluginTest.java exists but there's no sample-groovy-app directory equivalent to sample-android-app to demonstrate Groovy+Retrolambda integration. This creates a documentation gap and makes it harder for contributors to understand or test Groovy support. Adding a sample app with integration tests would improve clarity.

• [ ] Create sample-groovy-app/ directory mirroring sample-android-app structure
• [ ] Create sample-groovy-app/build.gradle with Groovy plugin + retrolambda configuration
• [ ] Add sample Groovy sources using lambdas in sample-groovy-app/src/main/groovy
• [ ] Add integration test in gradle-retrolambda/src/test/java/me/tatarka/ that builds and validates the sample

• Add test coverage for RetrolambdaUtil.groovy (no corresponding *UtilTest.java exists); verify utility methods like Java version parsing and file filtering work correctly across edge cases
• Document the Android Transform API integration flow in RetrolambdaTransform.groovy with inline comments; the current code lacks explanation of how scopes, jar inputs, and dir inputs map to retrolambda invocation
• Create a quickstart example in sample-android-app/README.md showing: exact steps to build with lambdas, how to verify bytecode was transformed (javap inspection), and how to troubleshoot common errors like missing JDK8

The gradle-retrolambda project has a moderate security posture with several areas of concern. The primary risks include the committed gradle-wrapper.jar binary file (which should be generated), outdated minimum Android Gradle plugin version requirements (1.5.0 is from 2015), and incomplete visibility into all transitive dependencies. The project lacks explicit security scanning and dependency vulnerability checking in its build pipeline. The codebase itself (Groovy/Java) does not show obvious injection vulnerabilities, hardcoded secrets, or misconfigurations in the analyzed files. However, the project targets older Java versions (6, 7, 8) and should ensure modern security practices are followed despite this legacy focus.

• Medium · Gradle Wrapper Security Risk — gradle/wrapper/gradle-wrapper.jar. The repository includes gradle/wrapper/gradle-wrapper.jar, which is a compiled binary file. This poses a security risk as it can be difficult to audit the contents and verify its integrity. The gradle wrapper should ideally be generated from the gradle-wrapper.properties file rather than committed as a binary. Fix: Remove gradle-wrapper.jar from version control. Use 'gradle wrapper' command to generate it, and ensure gradle-wrapper.properties specifies a verified gradle distribution URL with checksum validation enabled.
• Medium · Outdated Android Plugin Version Reference — build.gradle, gradle.properties. The build configuration references 'androidPluginVersion' as an external property without explicit version pinning. The README indicates minimum Android Gradle plugin version 1.5.0, which is significantly outdated (current versions are 7.x+). Older plugin versions may contain known security vulnerabilities. Fix: Update to the latest stable Android Gradle plugin version. Ensure all dependencies are regularly updated and vulnerability scanning is performed as part of the CI/CD pipeline.
• Low · Incomplete README Security Information — README.md. The README snippet is truncated and incomplete. Security best practices documentation appears to be cut off. This may indicate incomplete security guidance for users. Fix: Ensure complete security documentation is provided, including warnings about JDK8 downloads from official sources and any known vulnerabilities or workarounds.
• Low · Missing Dependency Verification — gradle-retrolambda/build.gradle. The build.gradle file shows dependency declarations but the complete dependency file content is not provided. Without viewing all transitive dependencies and their versions, potential vulnerable dependencies may exist. Fix: Run 'gradle dependencies' and use tools like 'gradle dependencyCheckAnalyze' (OWASP Dependency-Check plugin) to identify vulnerable transitive dependencies. Implement dependency version pinning and regular updates.
• Low · No License File Verification — LICENSE.txt, build.gradle. While a LICENSE.txt file exists, there's no evidence of license compliance checking or security scanning in the build process. Fix: Integrate license compliance checking tools (e.g., gradle-license-plugin) into the build process to identify potentially problematic dependencies.

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.