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/pxb1988/dex2jar 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

• 12 active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 2y ago
• ⚠ Concentrated ownership — top contributor handles 74% 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 pxb1988/dex2jar repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/pxb1988/dex2jar.

What it runs against: a local clone of pxb1988/dex2jar — 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 pxb1988/dex2jar | 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 2.x exists | Catches branch renames | | 4 | Last commit ≤ 686 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "pxb1988/dex2jar(\\.git)?\\b" \\
  && ok "origin remote is pxb1988/dex2jar" \\
  || miss "origin remote is not pxb1988/dex2jar (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 2.x >/dev/null 2>&1 \\
  && ok "default branch 2.x exists" \\
  || miss "default branch 2.x 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 686 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~656d)"
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/pxb1988/dex2jar"
  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).

dex2jar is a toolchain that converts Android DEX (Dalvik Executable) files to Java JAR/class files, and provides bidirectional smali/baksmali assembly. It includes a lightweight DEX reader/writer API similar to ASM, enabling reverse engineering and analysis of Android APKs by translating bytecode from the Dalvik VM format to the JVM format. Multi-module Gradle monorepo with two primary command modules: d2j-base-cmd (base infrastructure at com.googlecode.dex2jar.tools.BaseCmd), and d2j-jasmin and d2j-smali as specialized submodules. d2j-jasmin uses ANTLR3 (Jasmin.g grammar) for Jasmin assembly, d2j-smali uses ANTLR4 (Smali.g4), and dex-reader/writer core (not shown in file list) provides the DEX parsing/generation API.

Android security researchers, reverse engineers, and developers analyzing APKs who need to decompile DEX bytecode into readable Java class files or work with smali intermediate representation without relying on external proprietary tools.

Mature and production-ready: the project has been active since ~2010 (Google Code era), is hosted on GitHub with 1.7MB of Java code, includes CI via GitHub Actions and Travis CI, and has structured Gradle builds. However, commit recency data is not visible in the provided snapshot, so recent activity level cannot be confirmed.

Low-to-moderate risk: it is a single-maintainer project (pxb1988) with no visible test coverage metrics, though test directories exist (d2j-jasmin/src/test). The codebase is 12+ years old, so dependencies may be outdated (Gradle config references Maven Central without pinned versions). Breaking changes in Java/Gradle tooling between 1.8 target and modern JDK could cause build friction.

No specific recent activity is visible in the provided data. The version system is pinned to '2.x' from GITHUB_REF_NAME, suggesting active release track, but commit history and open issues cannot be assessed from the file listing alone.

Clone the repo, then build and package with: git clone https://github.com/pxb1988/dex2jar.git && cd dex2jar && ./gradlew distZip. Unzip the output from dex-tools/build/distributions/dex-tools-*.zip and run d2j-dex2jar.sh -f <apk-path> to convert an APK.

Daily commands: Invoke via shell scripts after building: ./gradlew distZip creates distributions in dex-tools/build/distributions/. Extract and run d2j-dex2jar.sh, d2j-jasmin tools, or d2j-smali tools. No dev server; this is a batch transformation toolchain.

• d2j-base-cmd/src/main/java/com/googlecode/dex2jar/tools/BaseCmd.java: Base class for all CLI tools; defines argument parsing and command execution pattern
• d2j-smali/src/main/antlr4/com/googlecode/d2j/smali/antlr4/Smali.g4: ANTLR4 grammar defining Smali syntax; changes here affect all smali parsing/assembly
• d2j-jasmin/src/main/antlr3/com/googlecode/d2j/jasmin/Jasmin.g: ANTLR3 grammar for Jasmin assembly language; core to Jar2Jasmin and Jasmin2Jar conversion
• d2j-jasmin/src/main/java/com/googlecode/d2j/jasmin/JasminDumper.java: Converts Java bytecode to Jasmin intermediate text format; critical for JAR→Jasmin pipeline
• build.gradle: Root Gradle config; defines version scheme, Java 1.8 target, manifest metadata, and shared dependency/task logic

Start in d2j-base-cmd/src/main/java/com/googlecode/dex2jar/tools/BaseCmd.java for command infrastructure. For DEX parsing logic, locate dex-reader module (not in top 60 files list—likely in a separate top-level folder). For smali/jasmin grammar changes, edit d2j-smali/src/main/antlr4/.../Smali.g4 or d2j-jasmin/src/main/antlr3/.../Jasmin.g and regenerate via Gradle. Add tests in d2j-jasmin/src/test/java/com/googlecode/d2j/tools/jar/test/ or parallel structure.

ANTLR3 vs ANTLR4: d2j-jasmin uses legacy ANTLR3 while d2j-smali uses ANTLR4; build tools and grammar syntax differ. Source encoding must be UTF-8 (enforced in build.gradle but can break on Windows if not set globally). Revision detection tries git/hg/env vars in sequence—build without .git or .hg metadata may show revision '-1'. Java 1.8 target is hardcoded; OpenJDK 9+ may introduce compilation warnings or runtime differences.

• Dalvik Executable (DEX) Format — Understanding DEX structure—class definitions, method bodies, string pools, type lists—is essential to using dex2jar effectively and debugging conversion issues
• ANTLR Parser Generators (ANTLR3 vs ANTLR4) — dex2jar uses both ANTLR3 (Jasmin.g) and ANTLR4 (Smali.g4); understanding their grammar syntax and runtime differences is critical for modifying parsers or upgrading tooling
• Smali/Baksmali Intermediate Representation — Smali is human-readable Dalvik assembly; dex2jar's smali module converts DEX↔Smali, making bytecode analysis and patching possible at an intermediate abstraction level
• Jasmin Assembly Format — Jasmin is text-based JVM bytecode assembly; dex2jar uses it as an intermediate format for DEX→JAR conversion, avoiding direct binary class file generation
• Java Bytecode and Class File Format — dex2jar outputs standard Java .class files; knowledge of bytecode opcodes, constant pools, and class file structure helps debug conversion artifacts and compatibility issues
• Lightweight Visitor Pattern (ASM-style API) — dex2jar's DEX reader/writer claims an ASM-like visitor pattern; understanding event-driven parsing enables efficient streaming processing of large DEX files without loading entire structures

• skylot/jadx — Modern Android APK/DEX decompiler with GUI; JADX is a contemporary alternative that handles DEX→Java conversion with better obfuscation handling
• google/smali — Original smali/baksmali project (referenced in code comments); dex2jar provides alternative smali implementations with escape sequence support
• ashutosh2k15/frida — Dynamic instrumentation framework for Android; complements dex2jar by enabling runtime analysis after static decompilation
• Sable/soot — Static analysis framework that can consume JAR output from dex2jar for bytecode transformation and analysis pipelines
• guardianproject/apktool — APK repackaging tool; often used in conjunction with dex2jar to rebuild modified APKs after DEX transformation

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 d2j-smali ANTLR4 grammar parsing

The d2j-smali module uses ANTLR4 grammar (Smali.g4) for parsing Android smali bytecode, but only has a single BaksmaliTest.java file. There are no tests for SmaliCodeVisitor.java, AntlrSmaliUtil.java, or the grammar rules themselves. This is critical for a parser-heavy tool to catch regressions when the grammar or visitor logic changes.

• [ ] Create d2j-smali/src/test/java/com/googlecode/d2j/smali/SmaliParsingTest.java with test cases for Smali.g4 grammar rules
• [ ] Add test cases for SmaliCodeVisitor.java covering method calls, type parsing, and register handling
• [ ] Add test cases for AntlrSmaliUtil.java utility methods with both valid and edge-case inputs
• [ ] Add sample smali files to d2j-smali/src/test/resources/smali/ directory for integration testing

Add unit tests for d2j-jasmin ANTLR3 grammar and Jasmin format conversion

The d2j-jasmin module has a Jasmin.g ANTLR3 grammar and conversion tools (Jar2JasminCmd, Jasmin2JarCmd, JasminDumper) but only one test file (Jasmin2jTest.java) with a single resource file (type.j). Critical conversion logic in JasminDumper.java and Jasmin2JarCmd.java lacks test coverage. A regression in jasmin parsing/generation could silently corrupt class files.

• [ ] Expand d2j-jasmin/src/test/java/com/googlecode/d2j/tools/jar/test/Jasmin2jTest.java with tests for all jasmin syntax features
• [ ] Add test cases for JasminDumper.java covering method generation, field handling, and annotation conversion
• [ ] Create more sample .j files in d2j-jasmin/src/test/resources/jasmins/ covering edge cases (generics, annotations, complex types)
• [ ] Add round-trip tests (jar → jasmin → jar) to ensure conversion fidelity

Modernize Gradle build and add GitHub Actions workflow for multi-JDK testing

The build.gradle uses deprecated syntax (testCompile instead of testImplementation, compile instead of implementation) and applies outdated plugins. The GitHub Actions workflow (gradle.yml) likely doesn't test across multiple JDK versions or publish artifacts. Given sourceCompatibility=1.8 but Java 8 is EOL, the project should validate compatibility with newer LTS versions (11, 17, 21) and automate release artifact publishing.

• [ ] Update build.gradle: replace 'compile' with 'implementation', 'testCompile' with 'testImplementation', remove deprecated 'maven' plugin
• [ ] Update .github/workflows/gradle.yml to test against Java 8, 11, 17, and 21 using matrix strategy
• [ ] Add automatic GitHub Releases artifact publication on tags (using gradle assemble output)
• [ ] Add a gradle wrapper version check and update gradle/wrapper/gradle-wrapper.properties if outdated

• Add unit tests for d2j-smali/Smali.g4 grammar edge cases: the test structure exists (d2j-jasmin/src/test/) but d2j-smali appears to have minimal test coverage. Create SmaliParserTest.java to verify escape sequences, type descriptors, and instruction parsing.
• Document the DEX reader/writer API with code examples: README mentions it has an ASM-like API but no examples exist. Add a docs/ folder with a tutorial on reading/writing DEX files programmatically.
• Upgrade ANTLR3 (Jasmin.g) to ANTLR4: d2j-smali already uses ANTLR4, but d2j-jasmin still uses legacy ANTLR3. Convert Jasmin.g to Jasmin.g4 and update build.gradle to unify tooling.

The dex2jar project has a moderate security posture with primary concerns in build infrastructure. Key issues include outdated Java compatibility (Java 8), deprecated Gradle plugins, severely outdated JUnit 4.11 dependency, and unsafe command execution in the build script. The codebase itself appears to be a transformation/conversion tool without obvious web-facing attack surfaces (no SQL injection, XSS, or authentication logic detected from the visible file structure). Immediate actions should focus on: (1) updating Java to LTS version 11+, (2) updating JUnit dependency, (3) replacing raw command execution with Gradle plugins, and (4) enabling dependency verification. The lack of visible CI/CD security configurations and the reliance on environment variables for build properties present additional risks in automated build environments.

• Medium · Outdated Gradle Build Configuration — build.gradle. The build.gradle file uses deprecated Gradle plugins ('maven' and 'eclipse') and the Java source/target compatibility is set to 1.8 (Java 8), which reached end-of-life in December 2030. This may expose the project to unpatched security vulnerabilities in the Java runtime and build tools. Fix: Update sourceCompatibility and targetCompatibility to at least 11 (LTS). Replace deprecated 'maven' plugin with 'maven-publish'. Consider using Java 17 or newer LTS versions for better security support.
• Medium · Outdated Test Dependency — build.gradle (dependencies section). JUnit 4.11 is severely outdated (released in 2013) and may contain known security vulnerabilities. Current stable versions are 4.13+ or JUnit 5.x. Fix: Update junit to at least '4.13.2' or migrate to 'junit:junit:4.13.2' or use JUnit 5 (org.junit.jupiter:junit-jupiter:5.9.x or newer).
• Medium · Command Execution via External Process — build.gradle (getRevision() function). The build.gradle file executes external commands using .execute() for git and mercurial revision detection without proper validation or sanitization. This could be exploited in compromised build environments. Fix: Use Gradle plugins for Git integration (e.g., 'gradle-git-properties' or 'org.ajoberstar.grgit') instead of raw command execution. Alternatively, validate command output and use ProcessBuilder with proper security context.
• Low · Missing Input Validation in Version String Processing — build.gradle (allprojects block, version property). The version property uses replaceAll() with a regex pattern that removes slashes and spaces without validating the GITHUB_REF_NAME source. Malicious input could potentially cause issues. Fix: Validate and sanitize the GITHUB_REF_NAME environment variable before processing. Use a whitelist approach for allowed characters in version strings.
• Low · Build Number Dependency on Environment Variable — build.gradle (jar manifest task). The build manifest includes a 'Build-Number' attribute that defaults to '-1' if the BUILD_NUMBER environment variable is not set. This could mask build traceability issues or be exploited in CI/CD pipelines. Fix: Use a more robust build numbering scheme. Consider integrating with CI/CD system APIs rather than relying on environment variables. Document required environment variables explicitly.
• Low · Missing Security Repository Configuration — build.gradle (repositories block). The build configuration uses 'mavenCentral()' and 'google()' repositories but does not enforce repository authentication, signing verification, or dependency integrity checks (e.g., checksums). Fix: Enable dependency verification in Gradle using 'dependencyVerification {}' block. Consider using Gradle's built-in dependency verification features or a Software Composition Analysis (SCA) tool.

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.