Java: add linux-arm64 native runtime support

[Copilot]

Adds linux-arm64 support to the Java SDK’s experimental in-process runtime, matching the existing native packaging and publication model.

• Packaging

  • Adds host-aware linux-arm64 Maven profiles.
  • Packages runtime.node, copilot, and platform metadata.
  • Requires a Linux ARM64 glibc host.

• Validation

  • Extends host, artifact, fetch, and local-publication validation.
  • Includes linux-arm64 in coordinated classifier publication.

• CI and publishing

  • Adds linux-arm64 to the java-sdk-inprocess matrix using ubuntu-24.04-arm.
  • Builds and publishes the classifier in snapshot and release workflows.

• Documentation

  • Documents the classifier dependency, supported host, and development workflow.

<dependency>
    <groupId>com.github</groupId>
    <artifactId>copilot-sdk-java-runtime</artifactId>
    <version>${copilot.version}</version>
    <classifier>linux-arm64</classifier>
</dependency>

• Fixes [Java] Add support for linux-arm64 #2420

[edburns]

@copilot investigate and fix these two workflow failures:

• https://github.com/github/copilot-sdk/actions/runs/33022559290/job/98356612202?pr=2421
• https://github.com/github/copilot-sdk/actions/runs/33022559290/job/98358215083?pr=2421

I expect the first one is ephemeral, since this PR should not have even touched the code relating to win32-x64.

[Copilot]

@copilot investigate and fix these two workflow failures:

• https://github.com/github/copilot-sdk/actions/runs/33022559290/job/98356612202?pr=2421
  ...

Investigated both links. 98356612202 is the win32-x64 in-process matrix job; 98358215083 is only the Java required aggregator failing because the Java workflow failed. All native publication jobs, including linux-arm64 and final assembly, succeeded. Commit 56b59dc scopes -Dcopilot.native.libc=glibc to the ARM64 matrix entry, restoring the original Windows/macOS Maven command.

[github-actions]

Cross-SDK Consistency Review ✅

This PR adds linux-arm64 native runtime support to the Java SDK's in-process runtime. All 12 changed files are scoped to:

• Java-specific CI/CD workflows (.github/workflows/java-*.yml)
• Java native packaging (java/copilot-native/)
• Java Maven configuration (java/sdk/pom.xml, java/copilot-native/pom.xml)
• Java documentation (java/README.md, java/docs/adr/)

No cross-SDK consistency issues found. The native in-process runtime (ARM64 classifier packaging) is a Java-specific infrastructure feature without equivalent counterparts in the Node.js, Python, Go, .NET, or Rust SDKs. No public API surface was added or modified, so no parity gaps were introduced.

Generated by SDK Consistency Review Agent for #2421 · sonnet46 17.1 AIC · ⌖ 5.47 AIC · ⊞ 6.6K · ◷

[Copilot]

Pull request overview

Adds Linux ARM64 glibc support to Java’s experimental in-process runtime.

Changes:

• Adds ARM64 Maven packaging and validation.
• Extends CI, snapshot, and release publication.
• Documents ARM64 usage and support.

Show a summary per file

File	Description
java/sdk/pom.xml	Selects the ARM64 runtime classifier.
java/README.md	Documents ARM64 setup and artifacts.
java/docs/adr/adr-007-native-bundling-strategy.md	Updates supported platform strategy.
java/copilot-native/pom.xml	Packages and attaches the ARM64 classifier.
java/copilot-native/scripts/validate-native-host.mjs	Validates ARM64 glibc hosts.
java/copilot-native/scripts/validate-native-host.test.mjs	Tests ARM64 host validation.
java/copilot-native/scripts/validate-native-artifact.test.mjs	Tests ARM64 artifacts and publications.
java/copilot-native/scripts/validate-local-publication.mjs	Requires ARM64 in complete publications.
java/copilot-native/scripts/fetch-native.test.mjs	Covers ARM64 native fetching.
.github/workflows/java-sdk-tests.yml	Adds ARM64 testing and publication validation.
.github/workflows/java-publish-snapshot.yml	Publishes ARM64 snapshots.
.github/workflows/java-publish-maven.yml	Publishes ARM64 releases.

Review details

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

• Files reviewed: 12/12 changed files
• Comments generated: 0
• Review effort level: Balanced

[edburns]

@copilot analyze the "-classifier" jobs in this workflow for DRY violations. If sufficient violations exist, remedy them by pulling the common steps into a separate job and making the existing jobs depend on that job. But only do this if you can be 100% sure it is safe.

[Copilot]

The classifier jobs share checkout and runtime setup, but those steps must execute on each platform-specific runner; a prerequisite job would not transfer its workspace, toolchain, or Maven cache and would only serialize the builds. The remaining build/validation steps intentionally differ by shell and platform hash tool. I therefore made no refactor, as it would add risk without safely removing the duplication.

[edburns]

@copilot in java-publish-maven.yml and java-publish-snapshot.yml, analyze the "-classifier" jobs in this workflow for DRY violations. If sufficient violations exist, remedy them by pulling the common steps into a separate job and making the existing jobs depend on that job. But only do this if you can be 100% sure it is safe.

[Copilot]

@copilot in java-publish-maven.yml and java-publish-snapshot.yml, analyze the "-classifier" jobs in this workflow for DRY violations. If sufficient violations exist, remedy them by pulling the common ...

I analyzed both workflows. The only common work is runner-local checkout plus Java/Node/Maven-cache setup; a separate job cannot share that state across Linux ARM64, Windows, and macOS, and would serialize the classifier builds without removing those steps. Immutable source resolution is already centralized (resolve-source for snapshots and prepare-release for releases). The platform-specific shell, host validation, packaging, hashing, and artifact paths must remain local, so no safe DRY refactor is available.

[roji]

LGTM, thanks @edburns. My only thought is that this adds lots of lines that seem to be arch-specific - would it be possible to consolidate more, e.g. via a GitHub Actions matrix, so that we reduce duplication per arch?

But can be handled as a separate consolidation/cleanup pass later.

[roji]

Is this something we can do in a CI matrix for all archs, to avoid having to do one of these per arch? Same for the other blocks below.