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/oblac/jodd 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

• 8 active contributors
• BSD-2-Clause licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 2y ago
• ⚠ Single-maintainer risk — top contributor 89% 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 oblac/jodd repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/oblac/jodd.

What it runs against: a local clone of oblac/jodd — 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 oblac/jodd | Confirms the artifact applies here, not a fork | | 2 | License is still BSD-2-Clause | 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 ≤ 783 days ago | Catches sudden abandonment since generation |

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(BSD-2-Clause)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"BSD-2-Clause\"" package.json 2>/dev/null) \\
  && ok "license is BSD-2-Clause" \\
  || miss "license drift — was BSD-2-Clause 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 "jodd-core/src/main/java/jodd/core/JoddCore.java" \\
  && ok "jodd-core/src/main/java/jodd/core/JoddCore.java" \\
  || miss "missing critical file: jodd-core/src/main/java/jodd/core/JoddCore.java"
test -f "build.gradle" \\
  && ok "build.gradle" \\
  || miss "missing critical file: build.gradle"
test -f "jodd-core/src/main/java/jodd/cache/Cache.java" \\
  && ok "jodd-core/src/main/java/jodd/cache/Cache.java" \\
  || miss "missing critical file: jodd-core/src/main/java/jodd/cache/Cache.java"
test -f "jodd-core/src/main/java/jodd/io/findfile/FindFile.java" \\
  && ok "jodd-core/src/main/java/jodd/io/findfile/FindFile.java" \\
  || miss "missing critical file: jodd-core/src/main/java/jodd/io/findfile/FindFile.java"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"

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

Jodd is a lightweight Java utility library and micro-framework suite (~1.7 MB, zero dependencies) providing modular tools for JSON parsing, HTML processing, HTTP clients, dependency injection, database mapping, transactions, and AOP. It's designed as a pick-and-choose alternative to heavyweight frameworks, letting developers import only what they need. Modular monorepo structure: jodd-core/ (base utilities), jodd-bean/, jodd-json/, jodd-db/, jodd-petite/ (DI), jodd-proxetta/ (AOP), jodd-madvoc/ (MVC), jodd-mail/, jodd-http/, etc. Each module has own build.gradle, src/main/java, and src/test/java. JFlex lexers in etc/jflex/ for parsing. Root build.gradle orchestrates Gradle wrapper build targeting Java 1.8.

Java developers building lean applications who want battle-tested utilities without framework bloat. Specifically targets teams using jodd-core for utilities, jodd-petite for DI, jodd-db for ORM, or jodd-json/jodd-lagarto for data processing—developers who prefer composable micro-libraries over monolithic Spring.

This is the v5 maintenance branch of a mature project (v6+ split into separate repos). The monorepo shows comprehensive test coverage, Gradle build with CI (Travis), and Codacy integration. However, the README warns this is the OLD monorepo—v6+ is the actively maintained version on Java 8+. Verdict: stable but transitioning; use v6 repos for new projects, this repo for legacy v5 codebases.

Key risks: Single maintainer (oblac) increases bus factor; migration to modular v6 repos means this monorepo is in maintenance-only mode with no active feature development. Zero dependencies is a strength, but monorepo structure makes selective upgrades harder. Last active development appears aimed at v6 split; no recent commits visible in provided data. Recommend v6 repos for new work.

This monorepo is in maintenance mode. Active development has moved to v6 split repositories (jodd-util, jodd-json, jodd-lagarto, jodd-http, jodd-mail, jodd-props, jodd-petite, jodd-proxetta, jodd-db promoted; v5 remainder in this repo). No feature work visible—focus is on stability and transitioning users to v6.

git clone https://github.com/oblac/jodd.git
cd jodd
./gradlew build

(Uses Gradle wrapper; no Maven. Requires Git and JDK 8+. Build produces jars in each module's build/libs/)

Daily commands:

./gradlew build              # Full build all modules
./gradlew jodd-core:build   # Build specific module
./gradlew test              # Run tests
./gradlew jmh:run           # Run JMH benchmarks (jodd-core)

No server to start—this is a library. For examples, check individual module READMEs or jodd.org docs.

• jodd-core/src/main/java/jodd/core/JoddCore.java — Main entry point for the Jodd framework initialization and configuration; every contributor must understand how core modules are bootstrapped.
• build.gradle — Root build configuration defining multi-module structure, dependencies, and release process; essential for understanding project organization and build flow.
• jodd-core/src/main/java/jodd/cache/Cache.java — Core cache abstraction interface used throughout the framework; critical for understanding caching patterns and extension points.
• jodd-core/src/main/java/jodd/io/findfile/FindFile.java — File discovery and scanning utility used across multiple modules for classpath scanning and resource location.
• README.md — Clarifies that this is the legacy monorepo; v6+ is split into separate repositories—critical context for avoiding wasted effort on deprecated modules.
• gradle.properties — Defines global version, Java target, and release artifact configuration; essential for managing cross-module consistency.
• STYLEGUIDE.md — Documents code style, naming conventions, and contribution standards; mandatory reading for code review alignment.

Add a new Cache implementation

1. Create new class extending AbstractCacheMap in jodd-core/src/main/java/jodd/cache/ (jodd-core/src/main/java/jodd/cache/YourNewCache.java)
2. Implement required eviction/expiration strategy (override methods like get, put, remove) (jodd-core/src/main/java/jodd/cache/AbstractCacheMap.java)
3. Add JMH benchmark class to compare performance against existing caches (jodd-core/src/jmh/java/jodd/cache/YourNewCacheBenchmark.java)
4. Update jodd-core/build.gradle if new external dependencies are required (jodd-core/build.gradle)
5. Document eviction behavior and usage in package-info.java (jodd-core/src/main/java/jodd/cache/package-info.java)

Add a new File Discovery filter

1. Create new comparator or filter class in jodd-core/src/main/java/jodd/io/findfile/ (jodd-core/src/main/java/jodd/io/findfile/YourNewFileFilter.java)
2. Implement Comparator<File> or use InExRules for include/exclude patterns (jodd-core/src/main/java/jodd/inex/InExRules.java)
3. Register filter in FindFile.java to apply during traversal (jodd-core/src/main/java/jodd/io/findfile/FindFile.java)
4. Update package-info to document filter behavior (jodd-core/src/main/java/jodd/io/findfile/FindFile.java)

Add a new Buffer type (e.g., FastStringBuffer)

1. Create new buffer class in jodd-core/src/main/java/jodd/buffer/ following FastByteBuffer pattern (jodd-core/src/main/java/jodd/buffer/FastStringBuffer.java)
2. Implement doubling strategy and reset/append methods for your type (jodd-core/src/main/java/jodd/buffer/FastByteBuffer.java)
3. Add JMH benchmark to measure allocation and copy overhead (jodd-core/src/jmh/java/jodd/buffer/FastStringBufferBenchmark.java)
4. Document buffer contract in package-info.java (jodd-core/src/main/java/jodd/buffer/package-info.java)

Contribute a fix to legacy v5 or earlier (monorepo)

1. Check README.md to confirm this is a v5 or earlier module (not v6+) (README.md)
2. Follow STYLEGUIDE.md for code style and naming (STYLEGUIDE.md)
3. Edit the relevant module file (e.g., jodd-core/src/main/java/jodd/...) (jodd-core/src/main/java/jodd/cache/LRUCache.java)
4. Update CHANGELOG.md with your fix description (CHANGELOG.md)
5. Submit PR following CONTRIBUTING.md guidelines and wait for approval (CONTRIBUTING.md)

• Gradle (multi-module build) — Enables parallel compilation, fine-grained dependency management, and easy publishing to Maven Central; supports JMH micro-benchmarks as first-class build type.
• JMH (Java Microbenchmark Harness) — Provides accurate performance measurement isolated from JVM noise; critical for validating optimization claims in zero-dependency utility library.
• Java generics & type erasure — Allows cache and buffer implementations to be type-safe at compile time while maintaining single implementation at runtime; reduces code duplication.
• Weak references in TypeCache — Prevents classloader memory leaks while caching class metadata for fast reflection-based discovery.

• Monorepo split
  • Why: undefined
  • Consequence: undefined

1. v5 vs v6 split: This monorepo is v5. v6 has moved to separate repos (jodd-util, jodd-json, etc). New code should target v6 repos, not this one. 2. Gradle wrapper required: Don't use system Gradle; always use ./gradlew. 3. Checkstyle is strict: Trailing whitespace, formatting, header comments all enforced—violations break builds. 4. Java 1.8 target: Some modern Java features unavailable; watch for language-level assumptions in PRs. 5. Module independence assumption: Each jar should have zero external deps; adding deps requires careful justification and affects entire ecosystem.

• Monorepo with modular jars — Jodd's v5 structure lets you build selective jars (jodd-core alone, jodd-db alone) with zero cross-module dependencies. Understanding this design clarifies why adding external deps is controversial—it would break the 'pick what you want' promise.
• Bytecode manipulation (AOP via proxetta) — jodd-proxetta generates dynamic proxies and interceptors without annotation processing or reflection overhead. Critical for understanding how Jodd achieves lightweight AOP without Spring-like complexity.
• Type converters and BeanUtil introspection — jodd-bean's TypeCache and BeanUtil provide fast, safe property access and type conversion without getters/setters overhead. Central to jodd-db ORM and form binding.
• Lexer-based HTML/form parsing (JFlex) — jodd-lagarto uses JFlex-generated lexers in etc/jflex/ for efficient HTML parsing with Jerry (jQuery-like API) and form extraction. Faster than DOM parsers for selective extraction.
• Zero-dependency constraint — Jodd's design philosophy forbids external dependencies. This makes version conflicts impossible but requires reimplementing some utilities (JSON, HTTP, mail). Understand this trade-off when proposing additions.
• Lightweight DI container (petite) — jodd-petite is ~100KB, no classpath scanning, explicit registration. Understand bean lifecycle, scopes, and injection modes as alternatives to Spring's auto-wiring.
• SQL mapping without ORM boilerplate (DbOom) — jodd-db uses DbOom (Object-Oriented Mapping) for type-safe queries without Hibernate overhead. Lightweight alternative to JPA for CRUD-heavy apps.

• oblac/jodd-util — v6 promoted split of jodd-core utilities; this is the active maintained version for core Java utils
• oblac/jodd-json — v6 promoted split of JSON parser/serializer; use this for new projects instead of jodd-json in this monorepo
• oblac/jodd-petite — v6 promoted split of lightweight DI container; the active, maintained version for dependency injection
• spring-projects/spring-framework — Primary alternative for DI/AOP; Jodd is intentionally lighter-weight and modular by contrast
• google/guava — Overlapping utility library (collections, caching, strings); Jodd is more micro-framework focused, Guava is pure utilities

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 unit tests for jodd-core buffer classes

The jodd-core/src/main/java/jodd/buffer directory contains 8 Fast*Buffer implementations (FastByteBuffer, FastCharBuffer, FastIntBuffer, etc.), but there are JMH benchmarks but no visible test files in the file structure. Adding thorough unit tests for edge cases (buffer overflow, capacity expansion, boundary conditions) would improve reliability and catch regressions as this is a foundational utility.

• [ ] Create jodd-core/src/test/java/jodd/buffer/ directory structure
• [ ] Write test classes for each buffer type covering: initial capacity, growth algorithm, reset/clear operations, and overflow scenarios
• [ ] Add property-based tests using QuickTheories or similar to validate buffer consistency across random operations
• [ ] Ensure tests verify the performance characteristics mentioned in BENCHMARKS.md

Migrate legacy Travis CI configuration to GitHub Actions workflow

The repo has .travis.yml for CI/CD, but modern GitHub repos should use GitHub Actions workflows. The .github/ directory exists but no workflow files are listed. Creating a GitHub Actions workflow would provide faster feedback, better integration with GitHub features, and align with current best practices for Java/Gradle projects.

• [ ] Create .github/workflows/test.yml with steps for: checkout, setup Java, run Gradle tests, and codecov upload
• [ ] Create .github/workflows/checkstyle.yml to run checkstyle.xml validations on PRs using the existing checkstyle-suppressions.xml
• [ ] Create .github/workflows/build.yml for full build validation on main branch using gradle build and publish workflow from gradle/publish-maven.gradle
• [ ] Update README.md with GitHub Actions badges replacing Travis CI badge

Add integration tests validating cross-module compatibility for Jodd v5 components

Since the README explicitly states this is the old monorepo and v6+ components are split into separate repos (jodd-util, jodd-mail, jodd-json), add integration tests that validate the interdependencies still work correctly in v5. This prevents breaking changes when users upgrade between versions and documents the module interaction patterns.

• [ ] Create jodd-core/src/test/java/jodd/integration/ directory with cross-module test classes
• [ ] Add tests validating jodd-core utilities work correctly with cache, buffer, and util modules together
• [ ] Document in CONTRIBUTING.md the process for testing module interactions before releases
• [ ] Add test results to CODE_COVERAGE.md showing coverage for integration scenarios

• Add missing unit tests for jodd-core/src/main/java/jodd/util/ utility classes (ArrayUtil, StringUtil, etc.). Check src/test/java for coverage gaps and write parameterized tests for edge cases (null, empty, boundary conditions).
• Improve Javadoc coverage: Scan modules (esp. jodd-bean, jodd-props) for public APIs missing @param, @return, @throws annotations. Use IDE inspection to identify gaps and submit doc-only PRs following STYLEGUIDE.md.
• Update migration guide in docs from v5→v6: Cross-reference which modules moved to which v6 repos (jodd-json → jodd-json repo, jodd-petite → jodd-petite repo, etc.) and list breaking changes. Add examples for each relocated tool.

The Jodd repository shows moderate security posture. Primary concerns include outdated Kotlin version (1.3.61 from 2019) and legacy build tools (JFlex 1.4.3). The project is marked as a legacy monorepo with newer components promoted to separate repositories with v6+. Immediate actions should focus on: (1) updating Kotlin dependency to current stable version, (2) removing or updating ancient JFlex versions, and (3) implementing automated dependency scanning in CI/CD. The BSD 2-Clause license is appropriate. No hardcoded secrets were identified in the provided file structure. Regular dependency audits and maintenance are critical for this utility library that is widely used.

• Medium · Outdated Kotlin Dependency — build.gradle (buildscript ext.kotlin_version). The build.gradle file specifies Kotlin version 1.3.61, which is significantly outdated (released in 2019). This version may contain known security vulnerabilities and compatibility issues. Current stable versions are 1.9+. Fix: Update Kotlin to the latest stable version (1.9.x or later). Review and test compatibility with the updated version before deployment.
• Medium · Potential Insecure Dependency Management — etc/jflex directory (JFlex-1.4.3.jar, JFlex-1.4.3-fixes.jar). The build configuration references JFlex 1.4.3 and 1.6.1 in the etc/jflex directory. Version 1.4.3 is extremely old (2009) and may contain unpatched vulnerabilities. Using old build tools can introduce security risks. Fix: Update to the latest stable JFlex version. Remove outdated JAR files if they are no longer in use. Ensure all build dependencies are regularly updated and monitored for vulnerabilities.
• Low · Deprecated Repository Configuration — gradle/wrapper/gradle-wrapper.jar. The project uses mavenCentral() which is appropriate, but the gradle-wrapper.jar files should be regularly verified. Gradle wrapper JAR files can be a supply chain attack vector if not properly maintained. Fix: Verify the integrity of gradle-wrapper.jar files using checksums. Consider using gradle-wrapper.properties to pin specific wrapper versions and validate them during CI/CD builds.
• Low · Incomplete Build Configuration Documentation — build.gradle (near end of file). The build.gradle file contains a comment '//versio' which appears incomplete and suggests the file may not be fully reviewed or maintained. This could indicate other configuration issues. Fix: Complete and review all configuration comments. Ensure all build configuration is properly documented and validated.

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.