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/java-decompiler/jd-gui 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 2y ago

• 4 active contributors
• GPL-3.0 licensed
• Tests present
• ⚠ Stale — last commit 2y ago
• ⚠ Small team — 4 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 95% of recent commits
• ⚠ GPL-3.0 is copyleft — check downstream compatibility
• ⚠ 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 java-decompiler/jd-gui repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/java-decompiler/jd-gui.

What it runs against: a local clone of java-decompiler/jd-gui — 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 java-decompiler/jd-gui | Confirms the artifact applies here, not a fork | | 2 | License is still GPL-3.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 ≤ 699 days ago | Catches sudden abandonment since generation |

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(GPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"GPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is GPL-3.0" \\
  || miss "license drift — was GPL-3.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 "app/src/main/java/org/jd/gui/App.java" \\
  && ok "app/src/main/java/org/jd/gui/App.java" \\
  || miss "missing critical file: app/src/main/java/org/jd/gui/App.java"
test -f "app/src/main/java/org/jd/gui/controller/MainController.java" \\
  && ok "app/src/main/java/org/jd/gui/controller/MainController.java" \\
  || miss "missing critical file: app/src/main/java/org/jd/gui/controller/MainController.java"
test -f "api/src/main/java/org/jd/gui/api/API.java" \\
  && ok "api/src/main/java/org/jd/gui/api/API.java" \\
  || miss "missing critical file: api/src/main/java/org/jd/gui/api/API.java"
test -f "api/src/main/java/org/jd/gui/spi" \\
  && ok "api/src/main/java/org/jd/gui/spi" \\
  || miss "missing critical file: api/src/main/java/org/jd/gui/spi"
test -f "app/src/main/java/org/jd/gui/service/extension/ExtensionService.java" \\
  && ok "app/src/main/java/org/jd/gui/service/extension/ExtensionService.java" \\
  || miss "missing critical file: app/src/main/java/org/jd/gui/service/extension/ExtensionService.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 699 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~669d)"
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/java-decompiler/jd-gui"
  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).

JD-GUI is a standalone graphical decompiler that reconstructs and displays human-readable Java source code from compiled .class files and archives (JAR, ZIP, etc.). It uses an ANTLR-based parsing pipeline to decompile bytecode into source, then renders it in a Swing GUI with syntax highlighting, navigation, and search capabilities. Two-module Maven-style layout: api/ contains SPI interfaces (ContainerFactory, PanelFactory, SourceLoader, etc.) for plugin extensibility, and app/ contains the main GUI application. Core decompilation logic is abstracted behind org.jd.gui.spi.SourceLoader implementations, allowing different decompiler backends. Feature capability is modeled via marker interfaces in api/src/main/java/org/jd/gui/api/feature/ (ContentSearchable, ContentSavable, LineNumberNavigable).

Java developers and reverse engineers who need to inspect third-party libraries, debug compiled code without source, or understand legacy applications. Contributors work on decompiler accuracy, UI polish, and plugin extensibility via the SPI system.

This is an actively maintained, production-ready project with a 20-year history in the Java decompiler space. The codebase is substantial (863K Java lines), properly modularized (separate api/ and app/ modules), and distributed as platform-specific installers (Windows .exe, macOS .tar, Linux .deb/.rpm). Build system is Gradle-based with clear artifact naming.

Single-maintainer risk is moderate given the project's niche and stable API surface. No visible continuous integration config (no GitHub Actions/Travis files listed) is a maintenance gap. The ANTLR grammar (20K lines) could be brittle on newer Java bytecode versions. Dependency quality is hard to assess without build.gradle details, but the project has survived decades so stability is likely high.

The repository structure suggests active maintenance of the core decompiler and GUI. Recent activity is not visible from the file list alone, but the presence of platform-specific build outputs (Windows .exe generation, macOS .tar, Debian .deb, RPM packaging) indicates ongoing release engineering. The SPI system (ContainerFactory, PanelFactory, etc.) suggests evolution toward extensibility.

git clone https://github.com/java-decompiler/jd-gui.git
cd jd-gui
./gradlew build
java -jar build/libs/jd-gui-1.0.0.jar

Daily commands:

./gradlew build              # Compile and package
java -jar build/libs/jd-gui-1.0.0.jar              # Run GUI

Or double-click the JAR / platform-specific executable.

• app/src/main/java/org/jd/gui/App.java — Main application entry point; initializes the GUI and orchestrates the decompiler workflow.
• app/src/main/java/org/jd/gui/controller/MainController.java — Core controller managing file opening, navigation, and UI interactions; essential for understanding request flow.
• api/src/main/java/org/jd/gui/api/API.java — Public API contract defining interfaces and SPIs for extensibility; all plugin developers must understand this.
• api/src/main/java/org/jd/gui/spi — Service Provider Interface definitions (ContainerFactory, PanelFactory, SourceLoader); extensibility backbone.
• app/src/main/java/org/jd/gui/service/extension/ExtensionService.java — Loads and manages SPI implementations at runtime; required for understanding plugin architecture.
• app/src/main/java/org/jd/gui/model/configuration/Configuration.java — Application configuration state and persistence; critical for maintaining feature toggles and user preferences.
• build.gradle — Project build configuration; defines dependencies, plugins, and assembly artifacts.

Add a new SPI Implementation (e.g., custom SourceLoader for a new JVM language)

1. Create a class implementing api/src/main/java/org/jd/gui/spi/SourceLoader.java (api/src/main/java/org/jd/gui/spi/SourceLoader.java)
2. Register your implementation in META-INF/services/org.jd.gui.spi.SourceLoader (META-INF/services/org.jd.gui.spi.SourceLoader (create if needed))
3. Package your jar with the service file; ExtensionService will auto-discover via ServiceLoader (app/src/main/java/org/jd/gui/service/extension/ExtensionService.java)
4. Override getPreferences() if your loader needs UI settings; implement PreferencesPanel SPI (api/src/main/java/org/jd/gui/spi/PreferencesPanel.java)

Add a new Preferences Panel for settings

1. Implement api/src/main/java/org/jd/gui/spi/PreferencesPanel.java with your UI component (api/src/main/java/org/jd/gui/spi/PreferencesPanel.java)
2. Register in META-INF/services/org.jd.gui.spi.PreferencesPanel (META-INF/services/org.jd.gui.spi.PreferencesPanel (create if needed))
3. Preferences are loaded by PreferencesPanelService and rendered in the Preferences dialog (app/src/main/java/org/jd/gui/service/preferencespanel/PreferencesPanelService.java)
4. Listen for PreferencesChangeListener events to react to setting changes (api/src/main/java/org/jd/gui/api/feature/PreferencesChangeListener.java)

Add a new Panel type for a custom content viewer

1. Implement api/src/main/java/org/jd/gui/spi/PanelFactory.java to create your Swing JPanel (api/src/main/java/org/jd/gui/spi/PanelFactory.java)
2. Optionally implement feature interfaces (ContentSearchable, ContentSavable, etc.) on your panel (api/src/main/java/org/jd/gui/api/feature)
3. Register in META-INF/services/org.jd.gui.spi.PanelFactory (META-INF/services/org.jd.gui.spi.PanelFactory (create if needed))
4. PanelFactoryService will instantiate your panel and inject it into tabs as needed (app/src/main/java/org/jd/gui/service/mainpanel/PanelFactoryService.java)

Add contextual actions (right-click menu items)

1. Implement api/src/main/java/org/jd/gui/spi/ContextualActionsFactory.java (api/src/main/java/org/jd/gui/spi/ContextualActionsFactory.java)
2. Return a collection of Swing Actions filtered by context (file type, tree node, etc.) (api/src/main/java/org/jd/gui/api/feature)
3. Register in META-INF/services/org.jd.gui.spi.ContextualActionsFactory (META-INF/services/org.jd.gui.spi.ContextualActionsFactory (create if needed))
4. ContextualActionsFactoryService collects actions and injects them into context menus (app/src/main/java/org/jd/gui/service/actions/ContextualActionsFactoryService.java)

• Java Swing — Cross-platform GUI framework; lightweight, no external runtime dependencies for desktop distribution
• Gradle — Build automation; generates JAR, Windows EXE, macOS DMG, Linux DEB/RPM distributions

JVM bytecode version assumption: The ANTLR grammar may not handle Java 17+ features (records, sealed classes, pattern matching bytecode); no visible version guards. SPI classloader isolation: Plugins are discovered via Java ServiceLoader — if a plugin jar is missing at launch, the app may silently fail to load features. No visible test directory: The repo structure doesn't show api/src/test/ or app/src/test/ in the top 60 files, suggesting sparse test coverage — risky for refactoring. GUI state persistence: No visible preferences/config system details — plugins may need to manage their own state (jd-gui.cfg mentioned in README). Platform-specific code: Windows .exe generation implies native launcher bundling — changes to startup flow affect multiple build outputs.

• Java Bytecode Format & Disassembly — JD-GUI's core task is parsing compiled .class file format (constant pool, method bytecode instructions) and reconstructing semantically equivalent source; understanding the JVM instruction set (INVOKEVIRTUAL, GETFIELD, etc.) is essential to debug decompilation errors.
• Service Provider Interface (SPI) & ServiceLoader — JD-GUI's entire extensibility model (ContainerFactory, SourceLoader, PanelFactory) uses Java's ServiceLoader mechanism to discover plugins at runtime without hardcoded dependencies; understanding this is required to write custom decompilers or UI renderers.
• ANTLR Parsing & AST Transformation — The 20K lines of ANTLR grammar in this repo define how decompiled source is parsed and potentially transformed (e.g., for code folding, formatting); modifying decompilation output handling requires understanding grammar rules and visitor patterns.
• Swing Event Dispatch & Component Lifecycle — JD-GUI renders decompiled code in Swing JTextPane/JEditorPane components; performance and responsiveness depend on understanding EDT threading, component repainting, and lazy-loading strategies for large files.
• Container & Archive Traversal (JAR/ZIP) — The ContainerFactory SPI abstracts loading and iterating archive entries; understanding zipfile structure, nested archives (JAR inside EAR), and lazy entry loading is critical for supporting complex project structures.
• Type Indexing & Search Optimization — The Indexer SPI enables fast type/method lookup in large codebases; understanding inverted indexing, trie structures, or suffix arrays can improve search performance on multi-megabyte JAR files.
• Control Flow Reconstruction from Bytecode — Decompiling bytecode requires reconstructing high-level control flow (loops, conditionals, try-catch blocks) from low-level jump instructions (GOTO, IF_ICMPNE, etc.); this is why decompiler bugs often manifest as malformed if/while statements.

• java-decompiler/jd-core — The core bytecode decompilation engine that JD-GUI wraps; understanding the decompiler output format is essential for UI rendering
• leibnitz/cfr — Alternative modern Java decompiler (handles Java 8+ features); could be plugged into JD-GUI via the SourceLoader SPI
• openjdk/jdk — Official Java source; necessary reference for understanding bytecode format changes and new language features that affect decompiler accuracy
• java-decompiler/jd-eclipse — Eclipse IDE plugin using the same decompiler engine; shares API design and plugin architecture patterns with JD-GUI
• google/procyon — Another Java decompiler with strong Java 8+ support (lambdas, streams); historical comparison point for feature parity

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 unit tests for SPI implementations in api/src/main/java/org/jd/gui/spi/

The SPI (Service Provider Interface) layer defines 10+ critical interfaces (ContainerFactory, SourceLoader, PanelFactory, Indexer, etc.) but there are no visible test files for these core extension points. Adding unit tests for mock implementations of these SPIs would catch integration bugs early and serve as documentation for plugin developers.

• [ ] Create api/src/test/java/org/jd/gui/spi/ directory structure
• [ ] Add tests for ContainerFactory.java covering container creation scenarios
• [ ] Add tests for SourceLoader.java and SourceSaver.java covering file I/O edge cases
• [ ] Add tests for Indexer.java covering index generation and querying
• [ ] Add mock implementations for UriLoader.java and PasteHandler.java to verify SPI contract

Add integration tests for MainController.java workflow

MainController is the core orchestrator for file opening, navigation, and panel management, but no test files are visible. Adding integration tests covering the main user workflows (open file → decompile → navigate → search) would prevent regressions and document expected behavior.

• [ ] Create app/src/test/java/org/jd/gui/controller/ directory
• [ ] Add tests for MainController.openFile() with various file types (.jar, .class, .zip)
• [ ] Add tests for navigation flow: PageChangeListener → PageChangeable interaction
• [ ] Add tests for search functionality integration with ContentSearchable implementers
• [ ] Test error handling for corrupted/invalid class files

Add GitHub Actions CI workflow for cross-platform builds and releases

The build.gradle produces platform-specific artifacts (jd-gui-windows-x.y.z.zip, jd-gui-osx-x.y.z.tar, jd-gui-x.y.z.deb) but there's no visible CI pipeline. A GitHub Actions workflow would ensure builds succeed on Windows/macOS/Linux and automate release artifact generation on tags.

• [ ] Create .github/workflows/build.yml with matrix strategy for [ubuntu-latest, macos-latest, windows-latest]
• [ ] Configure workflow to run './gradlew build' and verify all artifact types are generated
• [ ] Add step to upload platform-specific artifacts (zip, tar, deb) as workflow artifacts
• [ ] Create .github/workflows/release.yml triggered on git tags to auto-publish releases to GitHub Releases
• [ ] Add step to sign/verify artifacts if applicable for distribution security

• Add unit tests for SPI implementations: The keyFiles list doesn't show test/ directories. Create api/src/test/java/org/jd/gui/spi/ tests for ContainerFactory, SourceLoader, and PanelFactory to improve refactoring confidence.
• Document the plugin development flow: The api/ module is well-structured but README has no 'How to Write a Plugin' section. Write a PLUGIN_DEV.md with a minimal working example that adds a custom FileLoader for a new archive format.
• Add search indexing for type hierarchies: The Indexer.java SPI exists but no visible search-by-inheritance feature is mentioned. Extend the indexing to track extends/implements relationships and expose a TypeHierarchySearchable feature interface.

The JD-GUI codebase demonstrates a moder

• Medium · Missing Dependency Version Constraints — api/build.gradle, app/build.gradle. The build.gradle file shows version = '1.0.0' but does not display explicit dependency declarations. Without viewing the actual dependency configurations, there is a risk of using outdated or vulnerable transitive dependencies. Java decompiler projects often depend on ASM, BCEL, or similar bytecode manipulation libraries that have had historical vulnerabilities. Fix: Explicitly declare and pin versions of all dependencies. Use 'gradle dependencyUpdates' to check for vulnerable versions. Consider using dependency vulnerability scanning tools like OWASP Dependency-Check or Snyk in the CI/CD pipeline.
• Medium · Potential Unsafe Class Loading and Decompilation — api/src/main/java/org/jd/gui/spi/ContainerFactory.java, api/src/main/java/org/jd/gui/spi/FileLoader.java, app/src/main/java/org/jd/gui/service/fileloader/FileLoaderService.java. The application is a Java decompiler that loads and processes arbitrary CLASS files. This creates a risk of bytecode injection or malicious code execution if untrusted CLASS files are processed. The ContainerFactory, FileLoader, and related SPI interfaces may not have sufficient validation of loaded bytecode. Fix: Implement strict validation and sandboxing when loading CLASS files. Use SecurityManager policies if applicable. Validate file signatures and integrity. Process untrusted files in isolated environments. Document security implications in user documentation.
• Medium · Potential Path Traversal in File Operations — app/src/main/java/org/jd/gui/service/fileloader/FileLoaderService.java, app/src/main/java/org/jd/gui/controller/SaveAllSourcesController.java, api/src/main/java/org/jd/gui/api/feature/ContentSavable.java. The application handles file loading and saving operations (FileLoaderService, SaveAllSourcesController, ContentSavable). Without proper path validation, there is a risk of directory traversal attacks where specially crafted relative paths could write files outside intended directories. Fix: Implement strict path canonicalization and validation. Use java.nio.file.Path.normalize() and verify paths do not escape the intended directory. Reject paths containing '..', symbolic links to parent directories, or absolute paths when relative paths are expected.
• Low · Missing Security Configuration Documentation — README.md, Documentation. The README and codebase lack security guidelines for users regarding the risks of decompiling or analyzing untrusted CLASS files. No security policies or advisories are documented. Fix: Add a SECURITY.md file documenting: (1) Risks of processing untrusted CLASS files, (2) Best practices for secure usage, (3) Security reporting procedures, (4) Version update recommendations for addressing known vulnerabilities.
• Low · Potential XML External Entity (XXE) Vulnerability — app/src/main/java/org/jd/gui/service/configuration/ConfigurationXmlPersisterProvider.java. The ConfigurationXmlPersisterProvider suggests XML parsing is used for configuration persistence. XML parsers without proper configuration can be vulnerable to XXE attacks. Fix: Ensure XML parsers are configured to disable external entities, DTDs, and schema validation. Use SAXParserFactory with proper features disabled: 'http://apache.org/xml/features/nonvalidating/load-external-dtd' set to false, and 'http://xml.org/sax/features/external-general-entities' set to false.
• Low · No Input Validation Visible for Search Functionality — app/src/main/java/org/jd/gui/controller/SearchInConstantPoolsController.java, api/src/main/java/org/jd/gui/api/feature/ContentSearchable.java. SearchInConstantPoolsController and ContentSearchable interfaces suggest search functionality that may accept user input without visible sanitization, potentially leading to ReDoS (Regular Expression Denial of Service) if regex patterns are used. Fix: Implement input validation and sanitization for search queries. If regex is used, validate patterns and set execution timeouts. Consider using java.util.regex with a timeout mechanism or simpler string matching for user-provided searches.

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.