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/chewiebug/GCViewer 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 — Slowing — last commit 5mo ago

• Last commit 5mo ago
• 13 active contributors
• Other licensed
• CI configured
• Tests present
• ⚠ Slowing — last commit 5mo ago
• ⚠ Concentrated ownership — top contributor handles 58% of recent commits
• ⚠ 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 chewiebug/GCViewer repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/chewiebug/GCViewer.

What it runs against: a local clone of chewiebug/GCViewer — 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 chewiebug/GCViewer | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch develop exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 183 days ago | Catches sudden abandonment since generation |

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

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

# 4. Critical files exist
test -f "src/main/java/com/tagtraum/perf/gcviewer/GCViewer.java" \\
  && ok "src/main/java/com/tagtraum/perf/gcviewer/GCViewer.java" \\
  || miss "missing critical file: src/main/java/com/tagtraum/perf/gcviewer/GCViewer.java"
test -f "src/main/java/com/tagtraum/perf/gcviewer/imp/DataReaderFacade.java" \\
  && ok "src/main/java/com/tagtraum/perf/gcviewer/imp/DataReaderFacade.java" \\
  || miss "missing critical file: src/main/java/com/tagtraum/perf/gcviewer/imp/DataReaderFacade.java"
test -f "src/main/java/com/tagtraum/perf/gcviewer/imp/AbstractDataReaderSun.java" \\
  && ok "src/main/java/com/tagtraum/perf/gcviewer/imp/AbstractDataReaderSun.java" \\
  || miss "missing critical file: src/main/java/com/tagtraum/perf/gcviewer/imp/AbstractDataReaderSun.java"
test -f "src/main/java/com/tagtraum/perf/gcviewer/ctrl/impl/GCModelLoaderImpl.java" \\
  && ok "src/main/java/com/tagtraum/perf/gcviewer/ctrl/impl/GCModelLoaderImpl.java" \\
  || miss "missing critical file: src/main/java/com/tagtraum/perf/gcviewer/ctrl/impl/GCModelLoaderImpl.java"
test -f "src/main/java/com/tagtraum/perf/gcviewer/ctrl/impl/GCViewerGuiController.java" \\
  && ok "src/main/java/com/tagtraum/perf/gcviewer/ctrl/impl/GCViewerGuiController.java" \\
  || miss "missing critical file: src/main/java/com/tagtraum/perf/gcviewer/ctrl/impl/GCViewerGuiController.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 183 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~153d)"
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/chewiebug/GCViewer"
  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).

GCViewer is a Java GUI and CLI tool that parses, visualizes, and analyzes verbose garbage collection logs from Oracle/Sun JDK 1.6+, IBM, HP, and BEA JVMs. It generates charts and summary reports from GC output to help developers identify memory leaks, optimize heap sizes, and understand GC pauses—supporting modern collectors like G1 and OpenJDK 9+ unified logging format. Single monolithic Maven JAR. Core is under src/main/java/com/tagtraum/perf/gcviewer/: GCViewer.java is the GUI entry point, ctrl/GCModelLoader.java orchestrates parsing, and format-specific parsers live in the imp/ package (e.g., DataReaderSun1_6_0.java). CLI argument parsing uses GCViewerArgsParser.java. Assembly configs in src/main/assembly/ handle distribution packaging (Mac binary, etc.).

Java developers and DevOps engineers who need to diagnose GC performance issues in production applications. Specifically those running Oracle JDK 1.6–1.8, Java 9+ with unified logging, or other JVM implementations, who want visual analysis without manual log parsing.

Moderately mature and actively maintained. The project is a fork continuing work from Tagtraum Industries (original development 2004–2008), now at v1.37-SNAPSHOT with Travis CI/GitHub Actions pipelines, code coverage tracking, and multiple contributors. However, last visible commit age and open PR count are not shown in provided data—check the GitHub repo directly for current activity level.

Low-to-moderate risk. The codebase is Java-only with minimal external dependencies (see pom.xml), reducing supply-chain risk. Risk factors: single-maintainer (chewiebug) visibility in the file list; parsing complex GC log formats is fragile and version-specific, so Java GC format changes can break parsing; no obvious recent activity metadata provided, so check commit history for staleness.

Active development on Java 1.6+ GC log support, G1 collector parsing, and OpenJDK 9+ unified logging format (-Xlog:gc:...). GitHub Actions workflows in .github/workflows/pullrequest.yaml and CI/CD scripts in cicd/ suggest recent DevOps improvements. Dependometer config (dependometer/dependometer-gcviewer.xml) indicates dependency analysis is part of QA.

git clone https://github.com/chewiebug/GCViewer.git
cd GCViewer
mvn clean package
java -jar target/gcviewer-*.jar  # GUI
java -jar target/gcviewer-*.jar gc.log summary.csv chart.png  # CLI report

Daily commands: GUI: java -jar gcviewer-1.37-SNAPSHOT.jar (double-click JAR or run command). CLI report: java -jar gcviewer-1.37-SNAPSHOT.jar gc.log summary.csv [chart.png] [-t PLAIN|CSV|CSV_TS|SIMPLE|SUMMARY]. With rotated logs: java -jar gcviewer-1.37-SNAPSHOT.jar gc.log.0;gc.log.1;gc.log.2;gc.log.current summary.csv chart.png.

• src/main/java/com/tagtraum/perf/gcviewer/GCViewer.java — Main entry point for the GUI application; every contributor must understand how the application initializes and how it structures the main window.
• src/main/java/com/tagtraum/perf/gcviewer/imp/DataReaderFacade.java — Facade for reading GC logs from multiple JVM vendors; critical for understanding how logs are parsed and routed to appropriate readers.
• src/main/java/com/tagtraum/perf/gcviewer/imp/AbstractDataReaderSun.java — Base implementation for Sun/Oracle GC log readers; most modern JVM logs inherit from this, making it essential for parser enhancements.
• src/main/java/com/tagtraum/perf/gcviewer/ctrl/impl/GCModelLoaderImpl.java — Core loader that bridges parsed GC data into the in-memory model; essential for understanding data transformation pipeline.
• src/main/java/com/tagtraum/perf/gcviewer/ctrl/impl/GCViewerGuiController.java — Main GUI controller orchestrating UI interactions, file loading, and chart rendering; required for any UI or interaction changes.
• pom.xml — Build configuration and dependency management; required for understanding project structure, versioning, and build process.
• src/main/java/com/tagtraum/perf/gcviewer/imp/DataReaderSun1_6_0G1.java — G1 garbage collector specific parser; critical given the project's explicit goal of improving G1 support.

Add support for a new JVM garbage collector log format

1. Create a new DataReader implementation extending AbstractDataReaderSun or AbstractDataReader (src/main/java/com/tagtraum/perf/gcviewer/imp/DataReaderSun1_6_0.java)
2. Implement the regex patterns and event parsing logic specific to your GC log format (src/main/java/com/tagtraum/perf/gcviewer/imp/AbstractDataReaderSun.java)
3. Register the new reader in DataReaderFactory so it can be auto-detected (src/main/java/com/tagtraum/perf/gcviewer/imp/DataReaderFactory.java)
4. Add test cases validating parsing of sample logs from your new format (src/test/java/com/tagtraum/perf/gcviewer/imp/DataReaderTest.java)

Add a new export format for analysis results

1. Create a new class extending AbstractDataWriter (src/main/java/com/tagtraum/perf/gcviewer/exp/impl/CSVDataWriter.java)
2. Implement the write() method to output your desired format (src/main/java/com/tagtraum/perf/gcviewer/exp/AbstractDataWriter.java)
3. Register the new writer type in DataWriterType enum (src/main/java/com/tagtraum/perf/gcviewer/exp/DataWriterType.java)
4. Add instantiation logic in DataWriterFactory (src/main/java/com/tagtraum/perf/gcviewer/exp/impl/DataWriterFactory.java)

Add a new menu action or UI feature to the GUI

1. Create a new Action class extending existing action pattern (src/main/java/com/tagtraum/perf/gcviewer/ctrl/action/OpenFile.java)
2. Register your action in GCViewerGuiBuilder where menus and toolbars are constructed (src/main/java/com/tagtraum/perf/gcviewer/ctrl/impl/GCViewerGuiBuilder.java)
3. Wire up the action handler in GCViewerGuiController if it requires model state (src/main/java/com/tagtraum/perf/gcviewer/ctrl/impl/GCViewerGuiController.java)

• Java Swing — Cross-platform GUI framework available since Java 1.2; allows GCViewer to run on Windows, Mac, and Linux without modification. Requires only JDK 1.8+.
• Maven — Dependency management and build automation; allows easy packaging as single-JAR distribution. Supports multiple build profiles for different platforms.
• Regex-based parsing — Simple, stateless parsing approach suitable for log files with predictable formats across JVM versions. Avoids heavy grammar-based parsing overhead.
• Docker + CI/CD — Automated builds and testing across environments. GitHub Actions enable reproducible builds and artifact generation for releases.

• Single-JAR distribution with embedded GUI and CLI

  • Why: Maximize usability; users can double-click or run one command without installation. Simplifies distribution and versioning.
  • Consequence: Monolithic build increases JAR size. Both GUI and CLI dependencies bundled regardless of which is used.

• Regex-based line-by-line parsing instead of context-free grammar

  • Why:
  • Consequence: undefined

GC format fragility: Parsers rely on exact log format matching (regex-based); minor JVM flag changes (-XX:+PrintGCDateStamps presence/absence) break parsing. Test your log format against the specific parser (e.g., DataReaderSun1_6_0 for JDK 1.6–1.8). Unified logging complexity: OpenJDK 9+ -Xlog:gc parsing requires specific decorators (tags,uptime,level or tags,time,uptime,level); additional decorations fail silently or cause skips. Build requires GPG signing in CI: cicd/gpg/ contains encrypted keys; local builds may skip signing but release builds in CI need those secrets. No obvious test command: pom.xml likely has test config but standard mvn test should work.

• Generational Garbage Collection (Young/Old generation heap split) — GCViewer's core purpose is to analyze GC events across young and old generations; understanding why heaps are split into gen0/gen1/tenured spaces is essential to interpret the charts and metrics (pause times, reclamation rates) it displays

• openjdk/jdk — Official OpenJDK source; canonical reference for GC log format specifications and unified logging (-Xlog:gc) details since Java 9
• perftools/gctoolkit — Alternative GC log analysis tool from ServiceTitan; uses similar parsing strategy for Oracle/OpenJDK logs with Kotlin; good comparison for architecture
• alibaba/dragonwell8 — Alibaba's JDK 8 fork with enhanced GC observability and custom log formats; useful for testing GCViewer against non-standard JVM implementations
• spring-projects/spring-boot — Popular Spring Boot docs include GC tuning and logging setup examples; users often combine GCViewer with Spring Boot app GC logs for analysis

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 GCViewerArgsParser and command-line argument handling

The repo has a GCViewerArgsParser.java that handles CLI arguments (evidenced by the README showing CLI usage: java -jar gcviewer-1.3x.jar gc.log summary.csv [chart.png] [-t PLAIN|CSV|CSV_TS|SIMPLE|SUMMARY]), but there are no visible test files in src/test for this critical component. This is a common entry point for bugs and a high-impact area for test coverage.

• [ ] Create src/test/java/com/tagtraum/perf/gcviewer/GCViewerArgsParserTest.java
• [ ] Add tests for valid argument combinations (file input, CSV output, chart output, format types)
• [ ] Add tests for invalid/edge cases (missing required args, invalid format types, malformed paths)
• [ ] Test the GCViewerArgsParserException is thrown appropriately
• [ ] Verify test coverage with Maven surefire plugin configured in pom.xml

Add GitHub Actions workflow for automated release builds and artifact publishing

The repo has .travis.yml (legacy CI) and cicd/docker-build.bat (manual CI), but .github/workflows/pullrequest.yaml only tests PRs. There's no automated workflow for building releases and publishing JAR artifacts to GitHub Releases or Maven Central. This blocks smooth releases and contributor onboarding. The cicd/ folder hints at deployment complexity that should be automated.

• [ ] Create .github/workflows/release.yaml that triggers on git tags (e.g., v1.37)
• [ ] Configure Maven to build the JAR with version from git tag using maven-release-plugin
• [ ] Add step to create GitHub Release and upload gcviewer-*.jar artifact
• [ ] Document in cicd/README.md how to trigger a release (git tag + push)
• [ ] Consider integrating the existing docker-build.bat logic or deprecating it in favor of GitHub Actions

Add integration tests for GC log parsing across different JVM vendors (Oracle, IBM, HP, BEA)

The README states GCViewer supports 'Sun / Oracle, IBM, HP and BEA Java Virtual Machines', but there are no visible test fixtures or integration tests validating parsing accuracy for real-world GC logs from each vendor. This is core functionality and a high-risk area for regressions, especially as the project evolves post-2008.

• [ ] Create src/test/resources/gc-logs/ directory with sample GC logs from each vendor (Oracle, IBM, HP, BEA)
• [ ] Create src/test/java/com/tagtraum/perf/gcviewer/ctrl/GCModelLoaderIntegrationTest.java
• [ ] Add test cases that load each vendor's sample log using GCModelLoaderImpl and validate parsed GCModel properties (heap size, pause times, GC events)
• [ ] Test edge cases like G1 collector logs (mentioned in repo description) and log file rotation scenarios
• [ ] Ensure tests pass with both Maven surefire and the pull request GitHub Action workflow

• Add unit tests for GCViewerArgsParser.java CLI argument parsing—currently no test file visible in the structure; add src/test/java/com/tagtraum/perf/gcviewer/GCViewerArgsParserTest.java covering rotated log delimiters (;), chart format flags (-t PLAIN|CSV|...), and missing/invalid args: Easy
• Document supported JVM flags in README.md as a table—currently only prose descriptions exist for -XX:+PrintGCDetails, -XX:+PrintGCDateStamps, -Xverbosegc, etc. Add a structured table showing JVM versions, required/optional flags, and which DataReader* parsers support each: Easy
• Add parser support for recent OpenJDK/GraalVM GC logs with g1 collector prefix (GraalVM native-image GC logs differ from HotSpot G1)—check imp/ for existing G1 parser and extend or create new DataReaderGraalVM.java with test logs from GraalVM 22.x releases: Medium

GCViewer demonstrates a generally secure posture as a Java desktop application for log visualization. The main security concerns are moderate: encrypted keys stored in version control (though better than plaintext), reliance on outdated Java 1.8 runtime, and incomplete dependency visibility in the provided POM configuration. The application appears to have no obvious SQL injection, XSS, or critical misconfigurations visible in the file structure. Recommendations focus on modernizing the Java version, using proper secrets management, and ensuring comprehensive dependency scanning. The codebase lacks Docker/containerization security concerns as it's primarily a desktop application, though CI/CD pipelines should be reviewed for sensitive data exposure.

• Medium · Encrypted GPG Keys in Repository — cicd/gpg/pubring.gpg.enc, cicd/gpg/secring.gpg.enc. The repository contains encrypted GPG keys (cicd/gpg/pubring.gpg.enc and cicd/gpg/secring.gpg.enc) for CI/CD pipeline. While encrypted, storing keys in version control increases the attack surface and requires secure key management practices. Fix: Use a dedicated secrets management system (e.g., GitHub Secrets, HashiCorp Vault) instead of storing encrypted keys in the repository. Implement proper key rotation policies and access controls.
• Medium · Incomplete POM.xml Dependency Analysis — pom.xml. The pom.xml file is truncated in the provided content, making it impossible to fully analyze dependencies for known vulnerabilities. The project uses Maven, and outdated or vulnerable dependencies could be present. Fix: Run 'mvn dependency-check:check' or use OWASP Dependency-Check plugin to identify vulnerable dependencies. Regularly update dependencies and monitor security advisories.
• Low · Java 1.8 Runtime Requirement — README.md, src/main/java/com/tagtraum/perf/gcviewer/. The application requires Java 1.8 (8 years old as of 2024). While still functional, Java 1.8 is past its mainstream support and may lack recent security patches. Fix: Plan migration to Java 11 LTS or later (currently Java 21 is available). Update build configuration and test thoroughly to ensure compatibility.
• Low · GitHub Workflow Configuration Exposed — .github/workflows/pullrequest.yaml. The CI/CD workflow configuration files are visible in .github/workflows, which could expose build processes and pipeline details to potential attackers analyzing the repository. Fix: Review workflow files to ensure no secrets, API keys, or sensitive build information is exposed. Use GitHub Secrets for sensitive values and avoid logging sensitive data.
• Low · File I/O Operations Without Validation — src/main/java/com/tagtraum/perf/gcviewer/ctrl/action/OpenFile.java, src/main/java/com/tagtraum/perf/gcviewer/exp/. The application handles GC log file imports and exports (OpenFile.java, DataWriter implementations). Without proper input validation and sanitization, malformed files could potentially cause issues. Fix: Implement strict file type validation, size limits, and input sanitization. Use try-catch blocks with proper error handling. Validate file formats before processing.

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.