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/projectlombok/lombok 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 the board

• Last commit 2w ago
• 11 active contributors
• Distributed ownership (top contributor 42% of recent commits)
• Other licensed
• CI configured
• Tests present
• ⚠ Non-standard license (Other) — review terms

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

What it runs against: a local clone of projectlombok/lombok — 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 projectlombok/lombok | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 46 days ago | Catches sudden abandonment since generation |

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other 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"

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

Project Lombok is a Java compile-time annotation processor that automatically generates boilerplate code—getters, setters, equals, hashCode, toString, builders, and logging wrappers—via a single annotation on a class. It integrates directly into the Java compiler and IDEs (Eclipse, IntelliJ), eliminating hundreds of lines of repetitive code without runtime overhead. Monolithic structure with core annotation processing logic in src/core/, IDE plugin integration spread across src/eclipseAgent/ and src/netbeans/, build tooling in buildScripts/ (using Ivy for dependency management and custom Ant targets), and test suites in test/. The project uses Ant-based incremental compilation across Java versions and patches bytecode at compile time via lombok.patcher.

Java developers building enterprise applications, microservices, and data-heavy systems who want to reduce boilerplate while keeping code readable. Contributors are primarily Java language enthusiasts and IDE plugin developers who want to eliminate tedious code generation.

Highly mature and production-ready. The project has 5M+ lines of Java, a full CI/CD pipeline (GitHub Actions in .github/workflows/ant.yml), multi-JDK support (Java 6–14 compiler versions in buildScripts/ivy-repo/), and active Eclipse/IntelliJ plugin infrastructure. Lombok is widely adopted in enterprise Java ecosystems and maintained with regular updates.

Low risk for adoption, but moderate risk for contributing: the codebase heavily depends on internal compiler APIs (javac, Eclipse JDT, NetBeans) which change across Java versions, requiring careful testing across multiple JDK targets. The build system uses Apache Ivy and custom Ant scripts (build.xml, buildScripts/) rather than Maven, which can slow onboarding. Single-point-of-failure risk exists around IDE integration—breaking changes in IntelliJ or Eclipse APIs require rapid fixes.

The repo maintains active GitHub Actions CI (ant.yml, codeql-analysis.yml), supports Java 11–14 toolchains, and likely focusing on IDE compatibility. The presence of SECURITY.md and Tidelift sponsorship suggests ongoing security maintenance. Recent work appears centered on multi-version compiler support and IDE plugin robustness.

git clone https://github.com/projectlombok/lombok.git
cd lombok
ant clean dist

The build uses Apache Ant (no Maven/Gradle wrapper needed). Check build.xml for available targets like dist, test, eclipse, and intellij-plugin.

Daily commands:

ant compile          # Compile core and all agents
ant test             # Run test suite across supported JDKs
ant eclipse          # Create Eclipse project files
ant intellij-plugin  # Build IntelliJ plugin JAR
ant dist             # Package final lombok.jar

See buildScripts/compile.ant.xml and buildScripts/tests.ant.xml for detailed targets.

• build.xml: Master build orchestration file; defines dist, test, compile, and IDE plugin targets using Ant
• buildScripts/compile.ant.xml: Multi-JDK compilation logic; handles compilation against Java 6–14 compiler versions from ivy-repo/
• buildScripts/tests.ant.xml: Test harness configuration; defines how annotation processor tests run against different compiler backends
• src/core/lombok/javac/handlers/: Core handlers for javac annotation processing; where most boilerplate generation logic lives
• src/core/lombok/eclipse/handlers/: Eclipse IDE integration handlers; mirrors javac logic for Eclipse JDT AST manipulation
• buildScripts/ivy.xml: Ivy dependency configuration; declares lombok.patcher, javac compiler JAR versions, and IDE SDKs
• .github/workflows/ant.yml: CI/CD pipeline; runs tests on multiple Java versions via GitHub Actions

Adding a new annotation: Create handler in src/core/lombok/javac/handlers/ (for javac) and src/core/lombok/eclipse/handlers/ (for Eclipse). IDE support: Add IntelliJ handler in src/core/lombok/intellij/. Tests: Add test case in test/ with @RunWith(AnnotationProcessorTestRunner.class). Build changes: Edit build.xml or relevant buildScripts/*.ant.xml file. Start with copying an existing annotation handler as a template.

JDK Version Targeting: Build requires matching JDK versions in buildScripts/ivy-repo/ (e.g., net.java.openjdk.custom-javac8-1.8.0.xml); mismatched versions cause silent compiler failures. Bytecode Manipulation: Modifying generated code requires understanding both source AST (different for javac vs. Eclipse) and bytecode-level transformations via lombok.patcher. IDE Plugin API Drift: IntelliJ and Eclipse plugin APIs change frequently; test against multiple IDE versions explicitly or IDE support breaks silently. Ant Quirks: No Maven Central; custom Ivy repo in buildScripts/ivy-repo/ is authoritative—missing a dependency definition blocks the build entirely. Test Isolation: Test suite runs full compilation cycles; slow feedback loop; no standard JUnit runner, uses custom AnnotationProcessorTestRunner.

• Java Annotation Processing (JSR 269) — Lombok is fundamentally an annotation processor; understanding JSR 269's compile-time hooks, AbstractProcessor lifecycle, and RoundEnvironment is critical to modify handlers
• Abstract Syntax Tree (AST) Visitor Pattern — Lombok traverses and modifies compiler ASTs (javac Trees, Eclipse JDT nodes); visitor pattern understanding is essential to add new annotation handlers
• Bytecode Patching & Instrumentation — Lombok's core trick is patching bytecode at compile time via lombok.patcher rather than source generation; understanding ClassLoader patching and javassist-style manipulation is vital
• Multi-Target Compiler Support — Lombok must generate identical bytecode across javac, Eclipse JDT, and NetBeans; this means writing handlers twice (once per backend) with careful equivalence testing
• Service Provider Interface (SPI) — Lombok uses Java's SPI mechanism to auto-discover IDE plugins without hardcoding dependencies; see buildScripts/ivy-repo/projectlombok.org-spi-*.xml
• Ivy Dependency Management — Unlike Maven or Gradle, Lombok uses Ivy for version-pinned compiler SDKs and IDE artifacts; custom ivy.xml patterns differ from Gradle/Maven expectations
• Incremental Compilation — Lombok handlers must work incrementally (processing only changed files); understanding compiler caches and round-based annotation processing prevents race conditions

• google/auto — Google's annotation processing library for code generation; often compared to Lombok but generates source files instead of patching bytecode
• immutables/immutables — Generates immutable value classes via annotations; overlaps with Lombok's @Value but with stricter immutability guarantees
• mapstruct/mapstruct — Annotation-driven code generation for bean mapping; Lombok and MapStruct often used together in enterprise Java (note: buildScripts/mapstructBinding.ant.xml exists)
• eclipse/eclipse.jdt.core — Eclipse JDT core; Lombok's Eclipse integration directly depends on and patches JDT AST structures
• JetBrains/intellij-community — IntelliJ IDEA codebase; Lombok's IntelliJ plugin integrates with PSI and compiler extensions from this project

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 lombok.patcher integration across Java versions

The buildScripts/ivy-repo contains multiple lombok.patcher versions (0.50-0.58) supporting Java 6-14, but there's no visible test suite validating that annotation processing works correctly across these JVM versions. The ant.yml workflow could be enhanced with matrix testing. This is critical since lombok must maintain bytecode compatibility across major Java versions.

• [ ] Create buildScripts/tests-java-versions.ant.xml to define test targets for Java 6, 7, 8, 11, 13, 14
• [ ] Add test cases in src/core/lombok/core/tests/ validating patcher behavior on each supported Java version
• [ ] Update .github/workflows/ant.yml to run matrix builds against multiple JDK versions (reference vm-finder.ant.xml)
• [ ] Document in doc/git-workflow.txt how contributors should test across versions before submitting PRs

Create IDE-specific test suites for IntelliJ and Eclipse plugin integration

The repo has issue templates for intellij_plugin.md problems and eclipse-p2.ant.xml build artifacts, but no dedicated test suite validating that annotation processing works within IDE environments. This is a major pain point for users and contributors who face IDE-specific bugs that don't reproduce in CLI builds.

• [ ] Create buildScripts/test-ide-integration.ant.xml with targets for eclipse and intellij plugin testing
• [ ] Add src/test/java/lombok/ide/IntegrationTest.java to validate annotation processor registration in IDE contexts
• [ ] Document expected test output in doc/debug-insights/eclipse.txt and doc/debug-insights/vscode.txt
• [ ] Add CI workflow step in .github/workflows/ant.yml to run IDE integration tests post-build

Document and test MapStruct binding compatibility across lombok versions

buildScripts/mapstructBinding.ant.xml and doc/mapstruct-binding-maven-pom.xml exist, indicating MapStruct integration is supported, but there's no visible test coverage validating that @Builder, @Data, and other annotations work correctly with MapStruct's annotation processor. This integration point deserves explicit test cases and documentation.

• [ ] Create src/test/java/lombok/mapstruct/MapStructIntegrationTest.java with test cases combining @Data/@Builder with MapStruct @Mapper
• [ ] Add buildScripts/tests-mapstruct.ant.xml to run these tests as part of the build matrix
• [ ] Create doc/mapstruct-integration.markdown documenting known limitations, version compatibility, and setup instructions
• [ ] Update .github/workflows/ant.yml to include MapStruct integration tests in the CI pipeline

• Add test coverage for the @FieldNameConstants annotation generator in test/ (check if tests exist for all accessor patterns, especially with var-args fields and sealed records introduced in Java 15+)
• Document the Eclipse vs. IntelliJ handler mismatch for @Data with @Accessors(fluent=true) in IDE-specific test files (both backends should produce identical bytecode but likely diverge on edge cases)
• Implement missing Ivy dependency descriptors in buildScripts/ivy-repo/ for Java 15+ compiler versions (the repo maxes out at Java 14; add custom-javac15, custom-javac16, etc. following the existing XML pattern)

The Project Lombok repository demonstrates good security practices with a documented security policy and responsible disclosure procedures. The primary concerns are: (1) a keystore file potentially stored in version control, (2) outdated build dependencies and custom repositories that may contain vulnerabilities, (3) lack of visible automated dependency scanning in CI/CD workflows, and (4) incomplete security policy documentation. The project's nature as a compile-time only library reduces runtime attack surface. Recommendations focus on modernizing dependency management, implementing automated security scanning, and clarifying security documentation.

• Medium · Keystore File in Repository — buildScripts/lombok.jks. The file 'buildScripts/lombok.jks' appears to be a Java keystore file (.jks extension) stored in the repository. While this may be a test/demo keystore, storing keystore files in version control could expose sensitive cryptographic material if it contains production credentials or private keys. Fix: Verify the keystore does not contain production credentials. If it's a test keystore, document this clearly. Consider moving sensitive keystores outside version control and use environment variables or secure vaults for credential management in CI/CD pipelines.
• Low · Incomplete Security Policy Documentation — SECURITY.md. The SECURITY.md file appears to be truncated in the provided content ('...This process will involve the following steps:' followed by incomplete bullet points). This may indicate incomplete security documentation or disclosure policy guidelines. Fix: Complete the security policy documentation, ensuring all disclosure timelines, patching procedures, and contact information are clearly defined.
• Low · Dependency Management via Gradle Without Version Pinning — build.gradle (or equivalent). The provided Gradle dependency file uses 'files()' to reference '../lombok.jar' directly, which relies on local file system path. While this is not a direct vulnerability, it bypasses dependency version tracking and could lead to inconsistent builds if the local artifact changes unexpectedly. Fix: Consider using explicit version management with Maven Central or a private repository. Document the build dependency chain clearly to ensure reproducible builds.
• Low · No Evidence of Dependency Vulnerability Scanning — .github/workflows/. No evidence of automated dependency vulnerability scanning tools (such as OWASP Dependency-Check, Snyk, or similar) in the visible GitHub Actions workflows. Fix: Integrate automated dependency vulnerability scanning into the CI/CD pipeline (e.g., in ant.yml or codeql-analysis.yml) to detect known vulnerabilities in dependencies.
• Low · Custom Ivy Repository Configuration — buildScripts/ivy-repo/. The project uses custom Ivy repository definitions (buildScripts/ivy-repo/) with potentially outdated components (NetBeans 6.8beta, Java 6/7). Outdated dependencies may contain known security vulnerabilities. Fix: Audit and update all dependencies to current versions. Remove obsolete Java version toolchains (Java 6, 7) and update to modern, actively maintained versions. Verify all custom repository sources are trusted.

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.