WAIT — Stale — last commit 3y ago

• 16 active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 3y ago
• ⚠ Concentrated ownership — top contributor handles 67% of recent commits
• ⚠ Scorecard: marked unmaintained (0/10)
• ⚠ Scorecard: default branch unprotected (0/10)

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests, cross-checked against OpenSSF Scorecard}

VJTools is Vip.com's enterprise Java standards, libraries, and JVM diagnostic/monitoring tools. It provides three layers: coding standards with IDE formatters and SonarQube custom rules (in standard/), core libraries for text/collections/concurrency (vjkit/) and production patterns (vjstar/), and five specialized JVM tools (vjtop, vjmap, vjdump, vjmxcli) that observe heap allocation, thread activity, and memory distribution without requiring full heap dumps. Maven monorepo rooted at pom.xml with six leaf modules: standard/formatter/ (IDE XML configs), standard/sonar-vj/ (SonarQube plugin with checks in src/main/java/com/vip/vjkit/sonarvj/checks/), vjkit/, vjstar/, and four CLI tools (vjtop/, vjmap/, vjdump/, vjmxcli/). Documentation lives in docs/standard/ (12 chapters on Java conventions) and tool README.md files.

Java backend engineers at large e-commerce companies who need to enforce code standards, observe live JVM metrics (thread CPU usage, GC pressure, heap fragmentation) in production without restarting, and collect diagnostic data during incidents. Team leads use it to enforce formatting/static analysis at scale; SREs use vjtop/vjmap/vjdump for on-call incident response.

Actively maintained and production-ready. Last release was v1.0.8 (Sept 2018), CI via Travis, published to Maven Central (Sonatype OSS). Multi-module monorepo with 871K lines of Java indicates significant scale. No evidence of abandonment, but last visible commit date is not shown — check git history to confirm recent activity.

JDK version matrix risk: monorepo uses separate JDK7/8/9 Maven profiles with different module inclusion (JDK9 drops vjtop/vjmap/vjmxcli entirely), risking bitrot in older branches. SonarQube plugin (sonar-vj) is JDK8+ only. Single organization (Vip.com) maintains it, and English documentation is sparse (mostly Chinese). Community contribution process exists but activity level unclear.

Based on the file snapshot, recent focus appears to be on documentation (docs/ with detailed standard chapters, images, generated HTML). The pom.xml indicates 1.0.9-SNAPSHOT is in development. SonarQube integration code includes checks like BadConstantNameCheck, HardcodedIpCheck, MissingCurlyBracesCheck — rule set is actively curated. Check Issues/PRs tabs and latest commit history for real-time activity.

git clone https://github.com/vipshop/vjtools.git
cd vjtools
# Build against your JDK (7, 8, or 9 detected automatically via Maven profiles)
mvn clean install
# To build only core libraries (works on all JDKs):
mvn clean install -P jdk8
# For JDK8+, also includes SonarQube plugin

Daily commands: Each tool has its own binary/script: vjtop/vjmap/vjdump/vjmxcli are CLI tools built as self-contained JARs or shell scripts. Check vjtop/README.md, vjmap/README.md, vjdump/README.md, vjmxcli/README.md for exact invocation (e.g., ./vjtop.sh <pid> or java -jar vjmap.jar <pid>). For development, mvn clean install produces artifacts in target/ directories.

• pom.xml — Root POM defining the multi-module Maven project structure, dependency management, and distribution configuration for all vjtools components
• vjkit/pom.xml — Core library POM; vjkit is the fundamental utility library that all other tools depend on for base functionality
• vjkit/src/main/java/com/vip/vjtools/vjkit/base/ExceptionUtil.java — Core exception handling utility widely used across the codebase for consistent error handling patterns
• standard/sonar-vj/src/main/java/com/vip/vjkit/sonarvj/SonarPlugin.java — Entry point for the SonarQube plugin that enforces VJTools coding standards across the organization
• docs/standard/chapter01.md — First chapter of the VJTools Java coding standard; essential reading for understanding organizational best practices
• vjkit/src/main/java/com/vip/vjtools/vjkit/base/MoreValidate.java — Validation utility providing common assertion and validation patterns used throughout the libraries

• vjkit (Core Library) (Java 1.6+, Maven) — Provides reusable utility classes for exception handling, validation, collections, and runtime operations
  • Failure mode: Broken utility method causes failures in all dependent applications
• sonar-vj (SonarQube Plugin) (SonarQube API, Java AST parsing) — Registers and executes custom code quality checks enforcing VJTools standards
  • Failure mode: Plugin crash prevents SonarQube analysis; check misconfiguration produces false positives
• IDE Formatters (Eclipse/IntelliJ formatter schemas) — Provide XML configuration for consistent code style in Eclipse and IntelliJ IDEA
  • Failure mode: Malformed XML prevents IDE from loading formatter; inconsistent formatting across team
• JVM Tools (vjtop, vjmap, vjdump) — Shell scripts and Java utilities for observing JVM performance, memory

Add a new SonarQube code quality check

1. Create a new check class in standard/sonar-vj/src/main/java/com/vip/vjkit/sonarvj/checks/ (standard/sonar-vj/src/main/java/com/vip/vjkit/sonarvj/checks/BadConstantNameCheck.java)
2. Implement the check by extending the appropriate AST visitor class and annotate with @Rule (standard/sonar-vj/src/main/java/com/vip/vjkit/sonarvj/checks/BadConstantNameCheck.java)
3. Register the check in the rules list (standard/sonar-vj/src/main/java/com/vip/vjkit/sonarvj/SonarRulesList.java)
4. Create rule metadata files (.json and .html) in standard/sonar-vj/src/main/resources/com/vip/java/rules/ (standard/sonar-vj/src/main/resources/com/vip/java/rules/S115_java.json)

Add a new utility class to vjkit

1. Create new Java class in vjkit/src/main/java/com/vip/vjtools/vjkit/base/ following existing naming conventions (vjkit/src/main/java/com/vip/vjtools/vjkit/base/ObjectUtil.java)
2. Use @NotNull, @Nullable, and @VisibleForTesting annotations from the annotation package (vjkit/src/main/java/com/vip/vjtools/vjkit/base/annotation/NotNull.java)
3. Document with JavaDoc and add unit tests following test conventions (vjkit/pom.xml)

Update Java coding standards documentation

1. Edit relevant chapter file in docs/standard/ (chapters 1-12 cover different aspects) (docs/standard/chapter01.md)
2. Update table of contents if adding new sections (docs/standard/_sidebar.md)
3. Rebuild documentation using merge script if needed (docs/standard/merge.sh)

• Maven multi-module project — Enables separate versioning and packaging of standards, libraries, and tools while maintaining shared dependencies
• SonarQube plugin architecture — Integrates code quality checks directly into CI/CD pipelines across the organization for consistent standards enforcement
• IDE formatters (Eclipse/IntelliJ XML) — Enforces consistent code formatting at development time across different team members' IDEs
• Utility-first library (vjkit) — Provides reusable, validated components for common Java patterns reducing duplicate code and improving consistency
• Shell scripts for JVM tools — Provides lightweight, portable diagnostics without requiring JVM startup overhead for monitoring tasks

• Monorepo structure for standards, libraries, and tools

  • Why: Simplifies version coordination and ensures all components follow the same coding standards
  • Consequence: Single release cadence for unrelated components; larger repository size

• SonarQube rules as plugin rather than standalone linter

  • Why: Integrates with existing enterprise quality platforms and provides centralized rule management
  • Consequence: Requires SonarQube infrastructure; may conflict with other Sonar plugins

• Core utilities in separate vjkit module

  • Why: Allows other projects to depend on lightweight utilities without including tools or standards
  • Consequence: Must maintain backward compatibility across vjkit versions

• Does not provide runtime frameworks or application scaffolding
• Does not include testing frameworks or test utilities
• Does not handle authentication or security configuration
• Not a real-time monitoring platform; tools provide point-in-time diagnostics only
• Does not provide deployment or containerization solutions

JDK multi-version maze: Maven profiles auto-detect JDK version; building with wrong JDK skips modules silently (e.g., JDK9 omits all CLI tools). Verify mvn -version matches intended target. SonarQube plugin JDK8-only: sonar-vj won't build/deploy on JDK7; requires separate CI job. Tool binary paths: vjtop/vjmap/vjdump are shell scripts wrapping JARs; PATH setup required. Documentation in Chinese: docs/standard/ is primary reference but chapters 1-12 are Chinese; English summaries limited. Maven Central auth: releasing requires Sonatype JIRA access and GPG signing (see distributionManagement).

• Generational Heap Analysis (jmap parsing) — vjmap's core trick: parses jmap output to show OLD/NEW generation allocation separately without pausing the JVM; critical for diagnosing young GC churn vs. memory leaks in production
• JMX (Java Management Extensions) — vjmxcli and vjtop both consume JMX metrics (ThreadMXBean, MemoryMXBean, RuntimeMXBean) to observe live thread CPU time and heap without bytecode instrumentation
• SonarQube Custom Rules (visitor pattern) — sonar-vj implements Check classes that walk abstract syntax trees to enforce VIP's naming/style rules at scale across thousands of repos in CI; enables institutional code standards
• HotSpot Perf Counters — vjtop reads /proc/self/fd on Linux and parses JVM perf event data to identify which threads are spinning CPU without needing sampling or profiler overhead
• IDE Code Formatter XML (Eclipse/IDEA syntax) — vjtools-code-conventions-*.xml files allow enforcing spacing, bracket placement, import ordering at editor commit time; synchronized standards across heterogeneous teams
• Maven Multi-Module POM with JDK Profiles — pom.xml's jdk7/jdk8/jdk9 profiles conditionally include/exclude modules (e.g., vjtop drops in JDK9); requires careful CI strategy to avoid silent build failures
• Heap Dump Automation (vjdump scripts) — Shell scripts in vjdump/ coordinate jmap, jstack, jstat in one call to capture full diagnostic snapshot during production incidents without manual step-by-step commands

• alibaba/Arthas — Overlapping JVM diagnostics (thread/heap inspection) but more comprehensive with bytecode rewriting; complementary toolset for production troubleshooting
• alibaba/fastjson — Alibaba's JSON serialization library often paired with VJTools for performance-critical backends (mentioned in vjstar best practices context)
• google/guava — Canonical Java collections/concurrency library; vjkit provides VIP-specific extensions and patterns on top of Guava concepts
• eclipse/eclipse.jdt.core — Official Eclipse IDE; VJTools formatter config targets this engine; relevant for developers integrating standard into CI
• SonarSource/sonarqube — SonarQube server that sonar-vj plugin extends; required dependency for deploying VIP's custom code analysis rules

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 sonar-vj checks implementations

The standard/sonar-vj/src/main/java/com/vip/vjkit/sonarvj/checks/ directory contains 8 custom Sonar rule implementations (BadConstantNameCheck, CatchUsesExceptionWithContextCheck, HardcodedIpCheck, etc.) but there is no corresponding test directory visible in the file structure. Adding comprehensive unit tests would ensure these checks work correctly and prevent regressions when the Sonar framework is upgraded.

• [ ] Create standard/sonar-vj/src/test/java/com/vip/vjkit/sonarvj/checks/ directory
• [ ] Add unit tests for each check class (e.g., BadConstantNameCheckTest.java, HardcodedIpCheckTest.java) using SonarQube's testing framework
• [ ] Include both positive and negative test cases for each rule
• [ ] Update standard/sonar-vj/pom.xml to include test dependencies (junit, sonar-plugin-api for testing)

Add GitHub Actions workflow to replace Travis CI for multi-JDK testing

The repo uses .travis.yml for CI but the file is incomplete in the snippet. Modern GitHub Actions provide better integration, faster feedback, and can properly test all three JDK profiles (jdk7, jdk8, jdk9) defined in pom.xml simultaneously. This would validate builds across Java versions more reliably.

• [ ] Create .github/workflows/build.yml with jobs for JDK 7, 8, and 9
• [ ] Configure each job to run appropriate Maven profiles matching pom.xml (jdk7, jdk8 with sonar-vj, jdk9 limited modules)
• [ ] Add steps to compile, test, and verify the build for each profile
• [ ] Add workflow status badge to README.md pointing to GitHub Actions instead of Travis CI

Add missing documentation for sonar-vj rule customization examples

The sonar-vj module has rule JSON and HTML files (S1068_java.json, S1068_java.html, etc.) and Java check implementations, but there is no standard/sonar-vj/README.md file visible explaining how to extend these rules or integrate the plugin. New contributors cannot easily understand the structure or pattern for adding custom Sonar checks.

• [ ] Create standard/sonar-vj/README.md documenting the module's purpose and how it integrates with Sonar
• [ ] Document the rule definition pattern by referencing an existing check (e.g., HardcodedIpCheck.java) and its corresponding rule files
• [ ] Add step-by-step instructions for adding a new custom Sonar rule with code examples
• [ ] Link to the SonarQube plugin development documentation and explain the project structure

• Translate docs/standard/chapter01.md through chapter12.md to English and add to docs/ with parallel sidebar navigation (expanding non-Chinese audience without code changes)
• Add unit tests for standard/sonar-vj/src/main/java/com/vip/vjkit/sonarvj/checks/BadConstantNameCheck.java and other Check classes (currently no test directory visible; low-hanging test coverage win)
• Document SonarQube plugin installation & configuration in a new standard/sonar-vj/SETUP.md file with screenshots for IntelliJ/Eclipse IDE integration (gaps in setup instructions for less technical users)

The vjtools repository has a moderate security posture. Key concerns include outdated parent POM dependency management, incomplete visibility into all project dependencies, and limited security-focused static analysis rules. The project appears to be a library and standards repository without obvious hardcoded credentials or injection vulnerabilities in visible files. However, the codebase lacks explicit security governance (no SECURITY.md, no CVE tracking) and comprehensive security rule definitions. Recommendations: (1) Update all dependencies and implement continuous vulnerability scanning, (2) Implement security-focused Sonar rules beyond style/naming, (3) Establish vulnerability disclosure policy, (4) Add SBOM generation, (5) Enable Maven Dependency-Check in CI/CD pipeline.

• Medium · Outdated Parent POM Version — pom.xml (parent dependency). The project uses org.sonatype.oss:oss-parent version 7, which is significantly outdated. Current versions are much higher (7+ years old), potentially missing critical security updates and best practices for dependency management. Fix: Update to the latest stable version of oss-parent. Review and update all transitive dependencies for known CVEs using 'mvn dependency:tree' and Maven Dependency-Check plugin.
• Medium · SNAPSHOT Version in Production Build Configuration — pom.xml (artifactId: vjtools, version). The project version is set to '1.0.9-SNAPSHOT', suggesting active development. If this is deployed to production, snapshot artifacts can be replaced unexpectedly, creating supply chain risks. Fix: Use stable release versions in production. Implement CI/CD controls to prevent SNAPSHOT versions from reaching production environments. Consider using a Maven repository manager with strict access controls.
• Medium · Incomplete Dependency Information — pom.xml (dependencies section incomplete). The POM file provided is incomplete (truncated at plugin configuration). Cannot verify if all dependencies are explicitly declared, pinned to specific versions, and checked for known vulnerabilities. Fix: Provide complete POM content. Run 'mvn org.owasp:dependency-check-maven:check' to identify vulnerable dependencies. Pin all dependency versions explicitly and use dependency management section to control transitive dependencies.
• Low · Sonar Rule Implementation Lacks Security Focus — standard/sonar-vj/src/main/java/com/vip/vjkit/sonarvj/checks/. The sonar-vj module implements custom Sonar rules but appears to focus on naming conventions and code style rather than security vulnerabilities (e.g., hardcoded IP check exists but no SQL injection, XSS, or authentication checks visible). Fix: Add custom Sonar rules for security-critical issues: hardcoded credentials detection, SQL injection patterns, unsafe deserialization, unsafe cryptography, and authentication/authorization flaws. Reference OWASP Top 10 and CWE/SANS Top 25.
• Low · No Security Policy or Vulnerability Disclosure Process — Repository root. The repository lacks a SECURITY.md file or documented vulnerability disclosure process, making it unclear how security issues should be reported. Fix: Create a SECURITY.md file with: 1) Instructions for reporting security vulnerabilities privately, 2) Expected response timeframe, 3) PGP key for encrypted communications, 4) Reference to security contact email.
• Low · Missing Dependency License Verification — pom.xml and project root. While the project includes LICENSE.txt, there's no evidence of automated license compliance checking or SBOM (Software Bill of Materials) generation for dependencies. Fix: Add maven-license-plugin or Apache RAT to verify license compliance. Generate SBOM using CycloneDX or SPDX format. Document all transitive dependencies and their licenses.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

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/vipshop/vjtools 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.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live vipshop/vjtools repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/vipshop/vjtools.

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

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

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

# 4. Critical files exist
test -f "pom.xml" \\
  && ok "pom.xml" \\
  || miss "missing critical file: pom.xml"
test -f "vjkit/pom.xml" \\
  && ok "vjkit/pom.xml" \\
  || miss "missing critical file: vjkit/pom.xml"
test -f "vjkit/src/main/java/com/vip/vjtools/vjkit/base/ExceptionUtil.java" \\
  && ok "vjkit/src/main/java/com/vip/vjtools/vjkit/base/ExceptionUtil.java" \\
  || miss "missing critical file: vjkit/src/main/java/com/vip/vjtools/vjkit/base/ExceptionUtil.java"
test -f "standard/sonar-vj/src/main/java/com/vip/vjkit/sonarvj/SonarPlugin.java" \\
  && ok "standard/sonar-vj/src/main/java/com/vip/vjkit/sonarvj/SonarPlugin.java" \\
  || miss "missing critical file: standard/sonar-vj/src/main/java/com/vip/vjkit/sonarvj/SonarPlugin.java"
test -f "docs/standard/chapter01.md" \\
  && ok "docs/standard/chapter01.md" \\
  || miss "missing critical file: docs/standard/chapter01.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 1011 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~981d)"
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/vipshop/vjtools"
  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).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.