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/dragonwell-project/dragonwell8 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 the board

• Last commit 1d ago
• 27+ active contributors
• Distributed ownership (top contributor 18% of recent commits)
• GPL-2.0 licensed
• CI configured
• Tests present
• ⚠ GPL-2.0 is copyleft — check downstream compatibility

_{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 dragonwell-project/dragonwell8 repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/dragonwell-project/dragonwell8.

What it runs against: a local clone of dragonwell-project/dragonwell8 — 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 dragonwell-project/dragonwell8 | Confirms the artifact applies here, not a fork | | 2 | License is still GPL-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 ≤ 31 days ago | Catches sudden abandonment since generation |

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(GPL-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"GPL-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is GPL-2.0" \\
  || miss "license drift — was GPL-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 "common/autoconf/configure.ac" \\
  && ok "common/autoconf/configure.ac" \\
  || miss "missing critical file: common/autoconf/configure.ac"
test -f "Makefile" \\
  && ok "Makefile" \\
  || miss "missing critical file: Makefile"
test -f "common/autoconf/spec.gmk.in" \\
  && ok "common/autoconf/spec.gmk.in" \\
  || miss "missing critical file: common/autoconf/spec.gmk.in"
test -f "corba/src/share/classes/com/sun/corba/se/impl/activation/ORBD.java" \\
  && ok "corba/src/share/classes/com/sun/corba/se/impl/activation/ORBD.java" \\
  || miss "missing critical file: corba/src/share/classes/com/sun/corba/se/impl/activation/ORBD.java"
test -f ".github/workflows/build-linux.yml" \\
  && ok ".github/workflows/build-linux.yml" \\
  || miss "missing critical file: .github/workflows/build-linux.yml"

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

Alibaba Dragonwell8 is a downstream fork of OpenJDK 8 optimized for large-scale e-commerce and financial applications running on 100,000+ servers at Alibaba. It provides a production-grade Java runtime with Alibaba-specific performance enhancements, memory management improvements, and cloud-native features while maintaining compatibility with standard JDK 8 APIs. Monolithic JDK source tree structure: common/ contains autoconf build infrastructure; hotspot/ (inferred from hotspot-spec.gmk.in) houses the JVM; jdk/ contains standard library implementation; .github/workflows/ defines CI/CD pipelines for Linux builds, PR checks, and release submissions. Build uses GNU autoconf (configure.ac, spec.gmk.in) and Make (Makefile, *.gmk files).

Java application developers and operators at Alibaba and other enterprises running high-scale distributed systems on Linux/x86_64; DevOps teams deploying Java workloads in cloud environments; contributors who want to understand or extend an OpenJDK variant tailored for extreme scaling scenarios.

Production-ready and actively maintained. This is a mature fork of OpenJDK with automated CI/CD workflows (GitHub Actions in .github/workflows/), established release process (extended and standard editions), YUM package availability in Alibaba Cloud Linux 2, and regular release notes on the wiki. Commits and releases are ongoing.

Low risk for intended use cases (Linux/x86_64 only), but significant platform limitation—Windows, macOS, and ARM support are absent. As a downstream fork, it diverges from upstream OpenJDK and may lag security patches; integration burden falls on users to track both upstream and Dragonwell changes. Single-organization backing (Alibaba) means roadmap priorities may not align with general Java community needs.

Active development tracked via GitHub workflows: build-linux.yml for automated compilation, check_pr.yml for pull request validation, and test.yml for test suite execution. Release process managed through submit.yml. Ongoing maintenance evident from .jcheck/conf configuration (OpenJDK review/commit tooling), suggesting regular code review and release cycles.

Clone the repository: git clone https://github.com/dragonwell-project/dragonwell8.git. Configure the build environment: cd dragonwell8 && bash common/autoconf/autogen.sh && bash common/autoconf/configure. Build the JDK: make images (full build). For pre-built binaries, download from https://github.com/dragonwell-project/dragonwell8/releases or install via YUM: sudo yum install -y java-1.8.0-alibaba-dragonwell.

Daily commands: After build completion, the JDK is in build/linux-x86_64-normal-server-release/jdk/ (or similar, depending on configuration). Set JAVA_HOME to this path and execute: $JAVA_HOME/bin/java -version. For testing: run make test (uses embedded test framework from OpenJDK). For development, use bash common/autoconf/generated-configure.sh to regenerate configuration after edits to configure.ac.

• common/autoconf/configure.ac — Master build configuration script that defines all platform detection, compiler flags, and dependency resolution—essential for understanding how Dragonwell8 builds across different environments.
• Makefile — Top-level build orchestrator that delegates to autoconf-generated makefiles; critical entry point for the entire compilation pipeline.
• common/autoconf/spec.gmk.in — Template for build specifications that controls compiler options, optimization levels, and platform-specific settings for the JDK build.
• corba/src/share/classes/com/sun/corba/se/impl/activation/ORBD.java — Object Request Broker Daemon implementation; core runtime component for distributed object communication that Dragonwell optimizes for high-scale deployments.
• .github/workflows/build-linux.yml — CI/CD workflow defining how Dragonwell8 is compiled and validated on Linux/x86_64; shows current supported platform and test strategy.
• README.md — Project overview explaining Dragonwell8's purpose as Alibaba's optimized OpenJDK fork for e-commerce and distributed systems at 100,000+ server scale.

• Autoconf Build System (Autoconf, M4, Bash) — Detects platform capabilities (CPU, OS kernel, compiler version, libraries) and generates makefile variables; ensures JDK builds identically on all developer machines and CI.
  • Failure mode: Missing library (e.g., libX11 for AWT) or incompatible compiler causes configure to fail before build; developer must install missing dependencies.
• HotSpot JVM Compiler & GC — Executes Java

Add a new CORBA activation service

1. Create new Java class extending ServerManagerImpl in the activation package (corba/src/share/classes/com/sun/corba/se/impl/activation/)
2. Implement IDL interface in corba/src/share/classes/com/sun/corba/se/PortableActivationIDL/activation.idl (corba/src/share/classes/com/sun/corba/se/PortableActivationIDL/activation.idl)
3. Register service handler in CommandHandler.java alongside existing commands (corba/src/share/classes/com/sun/corba/se/impl/activation/CommandHandler.java)
4. Add build rules to corba/make/Makefile if new IDL compilation needed (corba/make/Makefile)

Optimize JDK compilation for a new platform

1. Add platform detection logic in common/autoconf/platform.m4 (common/autoconf/platform.m4)
2. Define platform-specific compiler flags in common/autoconf/flags.m4 (common/autoconf/flags.m4)
3. Add build target specification in common/autoconf/spec.gmk.in template (common/autoconf/spec.gmk.in)
4. Create CI/CD workflow in .github/workflows/ for new platform validation (.github/workflows/)

Integrate Alibaba-specific JVM optimizations

1. Document optimization goal and constraints in README.md under new section (README.md)
2. Add conditional compilation flags to common/autoconf/jdk-options.m4 (common/autoconf/jdk-options.m4)
3. Update build specifications in common/autoconf/spec.gmk.in with new feature flags (common/autoconf/spec.gmk.in)
4. Add validation tests in CI workflow .github/workflows/test.yml (.github/workflows/test.yml)

• Autoconf + GNU Make — Industry-standard portable build system for OpenJDK; enables cross-platform compilation with minimal custom tooling while maintaining strict compatibility with upstream OpenJDK.
• CORBA (Object Request Broker) — Provides location-transparent distributed object communication essential for Alibaba's 100,000+ server deployments; enables RPC without tight coupling.
• GitHub Actions for CI/CD — Native GitHub integration for automated validation on every commit; separates build certification (check_pr) from production builds (build-linux) for safety.
• Java Security (cacerts, SSL/TLS) — Mandatory for financial and e-commerce applications running on Dragonwell; validates identity in distributed payment and transaction systems.

• Linux/x86_64 only—no Windows, macOS, ARM support

  • Why: Alibaba's production infrastructure is standardized on Linux servers; reduces testing matrix and compiler configuration complexity.
  • Consequence: Lower barrier to aggressive optimization (e.g., CPU-specific intrinsics, kernel syscall tuning) but limits community adoption and cross-platform deployments.

• Downstream fork of OpenJDK instead of contributing upstream

  • Why: Allows rapid experimentation with Alibaba-specific optimizations (memory layout, GC tuning, distributed tracing) without upstream review cycles.
  • Consequence: Requires continuous rebase against upstream security patches and new features; increases maintenance burden but enables differentiation for e-commerce workloads.

• CORBA kept as core transport (not gRPC, not REST)

  • Why: Dragonwell inherits CORBA from OpenJDK 8 legacy; removes deployment friction for existing Alibaba systems built on RMI/CORBA.
  • Consequence: Newer greenfield services may prefer gRPC/REST, creating two-system architecture; CORBA perceived as outdated but proven at scale.

• Does not support Windows or macOS—Linux/x86_64 only.
• Does not implement new Java language features beyond OpenJDK 8 baseline—focuses on runtime optimization, not language innovation.
• Not a testing framework or performance benchmark suite—Dragonwell is the runtime foundation consumed by applications.
• Not a package manager or dependency resolver—relies on external Maven/Gradle for application dependency management.

Build requires a working OpenJDK 8 boot JDK (detected via --with-boot-jdk flag in configure); if missing, configure will fail silently. Linux/x86_64 only—attempts to build on other platforms will fail at configure time. Autoconf regeneration (autogen.sh) is required after modifying configure.ac; skipping this causes build inconsistencies. Build artifacts are large (~2–3 GB); disk space constraints may cause out-of-space errors. The jcheck tool (.jcheck/conf) enforces OpenJDK-style commit messages; non-conforming PRs will be rejected by CI.

• HotSpot JVM — Dragonwell uses HotSpot as its runtime engine; understanding JIT compilation, tiered compilation, and GC algorithms is essential for optimizing performance and debugging runtime issues
• Autoconf/Automake Build System — The entire codebase uses autoconf (configure.ac) and GNU Make (*.gmk files) for cross-platform compilation; you must understand ./configure options and Makefile targets to modify builds
• OpenJDK Code Review (JCheck) — Dragonwell enforces OpenJDK's commit message and review standards (.jcheck/conf); PRs must pass jcheck validation or will be auto-rejected
• Tiered Compilation — Dragonwell optimizes for large-scale workloads using HotSpot's tiered compilation (C1 + C2 tiers); understanding compiler tiers helps tune JVM flags like -XX:TieredStopAtLevel
• Garbage Collection (G1GC, CMS) — Dragonwell's performance for e-commerce/finance workloads depends heavily on GC tuning; the codebase contains optimizations for pause time reduction and throughput
• Fork-based Development Model — Dragonwell is a 'friendly fork' of OpenJDK with its own release cycle; understanding how to track upstream changes and resolve merge conflicts is critical for long-term maintenance
• Linux/x86_64 Platform Abstraction — The codebase uses platform-specific code in hotspot/src/os/linux/ and hotspot/src/cpu/x86/; Dragonwell's x86_64-only stance means no ARM/Windows porting overhead, but also limits future expansion

• openjdk/jdk8u — Upstream OpenJDK 8 maintenance fork that Dragonwell8 is based on; critical for tracking security patches and API compatibility
• alibaba/dragonwell11 — Alibaba's downstream fork of OpenJDK 11; if you need newer Java version with same Alibaba optimizations, this is the next step
• alibaba/dragonwell-serverless-adapter — Companion serverless runtime adapter for Dragonwell; used in .github/actions/build-serverless-adapter for cloud-native deployments
• openjdk/jdk — Upstream OpenJDK mainline (latest development); useful for understanding HotSpot VM evolution and backporting future enhancements
• eclipse-openj9/openj9 — Alternative JVM implementation (IBM/Eclipse); reference for understanding different JVM design choices beyond HotSpot

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 GitHub Actions workflow for cross-platform build validation

The repo has build workflows for Linux (build-linux.yml) but the file structure shows toolchain configurations for Windows (common/autoconf/toolchain_windows.m4, common/autoconf/basics_windows.m4). There's no corresponding Windows CI workflow. Adding a build-windows.yml workflow would catch platform-specific build issues early and validate the Windows toolchain configurations that currently lack automated testing.

• [ ] Create .github/workflows/build-windows.yml based on build-linux.yml structure
• [ ] Configure Windows-specific build flags and dependencies using common/autoconf/toolchain_windows.m4
• [ ] Add matrix strategy to test multiple Windows versions/architectures
• [ ] Reference common/autoconf/configure.ac to ensure all necessary build steps are covered
• [ ] Test against the boot JDK configuration defined in common/autoconf/boot-jdk.m4

Create comprehensive build configuration documentation

The repo has complex autoconf setup (common/autoconf/) with many .m4 macro files and platform-specific configurations, but there's no dedicated guide explaining the build system. New contributors struggle to understand how to configure builds for different platforms. Document the build configuration system with examples for common scenarios.

• [ ] Create docs/BUILD_CONFIGURATION.md explaining the autoconf setup in common/autoconf/
• [ ] Document key macro files: platform.m4, toolchain.m4, jdk-options.m4, and their purposes
• [ ] Add platform-specific configuration examples for Linux and Windows using toolchain_*.m4 files
• [ ] Include troubleshooting section referencing common/autoconf/help.m4
• [ ] Add examples showing how to use generated-configure.sh and configure scripts

Add test coverage for Dragonwell-specific performance features

The README mentions Dragonwell is 'optimized for online e-commerce, financial, logistics applications' but there are no specific tests validating Dragonwell-specific enhancements. The existing test.yml workflow exists but likely only runs standard JDK tests. Add a new test suite that validates Dragonwell-specific optimizations and features.

• [ ] Create test/dragonwell-specific directory for Dragonwell feature tests
• [ ] Add performance regression tests for documented Dragonwell optimizations
• [ ] Create .github/workflows/test-dragonwell-features.yml to run these tests in CI
• [ ] Reference THIRD_PARTY_README to understand any contributed optimizations
• [ ] Document expected performance metrics in test files for e-commerce/financial use cases

• Documentation: Add a BUILDING.md guide with explicit step-by-step instructions for different Linux distributions (CentOS, Ubuntu, Debian), including boot JDK installation and required packages (currently scattered across README and autoconf docs)
• CI/Testing: Expand .github/workflows/test.yml to run a subset of the OpenJDK test suite on each PR (currently check_pr.yml only validates format); add test result summaries to PR comments
• Build System: Add a Dockerfile to common/ that encapsulates the build environment (boot JDK, autoconf, build-essentials), reducing setup friction for contributors on non-Linux hosts or without pre-installed dependencies

The Dragonwell8 JDK codebase shows reasonable security maturity as a downstream OpenJDK distribution. No critical vulnerabilities were identified in the visible file structure. Primary concerns are: (1) The vulnerability disclosure process could be more robust with Dragonwell-specific contact information, (2) Build system security should be hardened to prevent supply chain attacks, (3) Third-party dependencies require continuous monitoring. The project benefits from inheriting OpenJDK's security practices but should establish additional safeguards for its specific implementation and customizations. Recommend implementing automated security scanning in CI/CD pipelines and maintaining an up-to-date software bill of materials (SBOM).

• Medium · Potential Vulnerability Disclosure Policy Gap — SECURITY.md. The SECURITY.md file redirects users to the OpenJDK Vulnerability Policy without establishing a specific security contact or response process for Dragonwell-specific vulnerabilities. This could delay vulnerability patching for Dragonwell-specific issues. Fix: Enhance SECURITY.md to include: 1) Dragonwell-specific security contact email, 2) Expected response timeframe, 3) Whether Dragonwell has additional vulnerabilities beyond OpenJDK, 4) A clear disclosure process specific to the project.
• Low · Exposed CA Certificate Bundle — common/security/cacerts, common/security/cacerts.list.txt. The file 'common/security/cacerts' appears to be a CA certificate store. While standard in JDKs, ensuring this is the default trusted store without unauthorized modifications is important. Fix: Verify that: 1) The cacerts file matches the official JDK distribution, 2) No unauthorized CAs have been added, 3) The file permissions are restricted (644 or similar), 4) Include integrity checks in the build process.
• Low · Build Configuration Security — common/autoconf/, Makefile, configure, corba/make/. Multiple build configuration files (*.gmk, configure scripts, and autoconf files) are present. These are potential attack vectors if the build environment is compromised, and could introduce malicious code into the compiled JDK. Fix: Implement: 1) Build artifact signing and verification, 2) Build environment isolation, 3) Source code provenance checks, 4) Secure build documentation, 5) Regular audit of build scripts.
• Low · Third-Party Dependencies Tracking — THIRD_PARTY_README, corba/src/ (and likely other modules). The presence of 'THIRD_PARTY_README' suggests external dependencies are used. Without seeing the detailed contents, it's unclear if all dependencies are regularly audited for vulnerabilities. Fix: Ensure: 1) All third-party dependencies are documented with versions, 2) Regular dependency scanning for CVEs, 3) License compliance checking, 4) Automated dependency updates, 5) Software composition analysis (SCA) in CI/CD.

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.