Manage Azure Batch Compute Jobs

Azure Batch SDK for Java is a client library for running large-scale parallel and high-performance computing (HPC) batch jobs in Azure, built around five core concepts: a pool (a collection of compute nodes), a job (a logical grouping of tasks), a task (a single unit of computation), a node (the VM executing tasks), and a job schedule (recurring job creation). It authenticates with Microsoft Entra ID via DefaultAzureCredentialBuilder (recommended, both sync and async clients) or with shared-key credentials via AzureNamedKeyCredential.

Pool operations cover creating a pool with a VM image reference (publisher/offer/SKU) and a target mix of dedicated and low-priority nodes, getting and listing pools, resizing a pool's dedicated/low-priority node counts (a long-running operation tracked with a SyncPoller), enabling autoscale with a formula evaluated on an interval, and deleting a pool. Job operations cover creating a job against a pool with a priority and constraints (maxWallClockTime, maxTaskRetryCount), getting and listing jobs, reading task-count summaries (active/running/completed), terminating a job with a reason, and deleting it.

Task operations range from a single command task, to a task with exit-code-range-mapped actions (e.g. treating exit codes 2-4 as fatal and terminating the job) and a scoped, non-admin user identity, to bulk creation - a task collection (up to 100 tasks in one call) or createTasks for an unbounded number of tasks in a loop. Tasks can be read individually or listed, their stdout/stderr files retrieved directly, and terminated. Node operations list a pool's nodes, reboot one, and fetch its remote-login IP/port for direct access. Job schedules create a recurring job definition with a recurrence interval and a "do not run until" delay, and can be read back for their current state. Errors surface as a typed BatchErrorException carrying a BatchError with a code (like PoolNotFound) and message, letting you branch on the specific failure.

Use it when you need to programmatically provision compute pools and run large numbers of parallel/HPC tasks against them - batch processing, simulations, or bulk data jobs - rather than a single long-running service. Prefer Entra ID over shared-key credentials, and for pool management specifically, its own best practices point to the separate azure-resourcemanager-batch management SDK when managed-identity-based pool control is needed, rather than this data-plane client.

Input is pool/job/task specifications: VM configuration, node counts or an autoscale formula, job priority and constraints, and the command each task runs. Output is created/updated Batch resources and their state, task exit codes and output files, and task-count progress summaries. Install it with:

<dependency>
    <groupId>com.azure</groupId>
    <artifactId>azure-compute-batch</artifactId>
    <version>1.0.0-beta.5</version>
</dependency>

Its own best practices: prefer Entra ID authentication, use createTaskCollection/createTasks rather than one-by-one task creation, handle long-running operations (pool resize/delete) properly with pollers, monitor progress via getJobTaskCounts, always set maxWallClockTime/maxTaskRetryCount constraints, use low-priority nodes for fault-tolerant workloads to cut cost, and enable autoscale to size pools to actual workload.

It's the com.azure:azure-compute-batch data-plane client, pairing with azure-identity for Entra ID auth and, for pool/account management via managed identity, the separate azure-resourcemanager-batch management SDK.

Java developers and infrastructure engineers running large-scale parallel or HPC batch workloads on Azure who need programmatic control over pools, jobs, tasks, and node scaling rather than manual portal configuration.