Manage Azure Blob Storage with Java SDK

This skill builds blob storage applications with the Azure Storage Blob SDK for Java (com.azure:azure-storage-blob, version 12.33.0). It covers a three-tier client hierarchy: BlobServiceClient (account-level, built via SAS token, connection string, or DefaultAzureCredential), BlobContainerClient (obtained from the service client or built directly), and BlobClient (a specific blob, addressable with a folder-style path like folder/subfolder/myblob.txt). Containers are created directly or idempotently (createIfNotExists). Uploads cover a string or byte payload via BinaryData (with an overwrite flag), uploading directly from a local file, uploading from an InputStream via the lower-level BlockBlobClient, uploading with full options (BlobHttpHeaders for content-type/cache-control, custom metadata) via BlobParallelUploadOptions, and a conditional "upload only if the blob doesn't already exist" pattern using BlobRequestConditions().setIfNoneMatch("*"). Downloads mirror this: to BinaryData, to a local file, to an OutputStream, or via a raw BlobInputStream for manual buffered reads; uploads can also go through a BlobOutputStream for streaming writes. Listing blobs supports a flat listing, prefix-filtered listing (simulating a virtual directory), and hierarchical listing with a delimiter that distinguishes prefixes ("directories") from actual blobs. Deletion covers plain delete, deleteIfExists, and deleting with snapshots included. Copying a blob uses beginCopy (an async, pollable operation for large blobs or cross-account copies) or the synchronous copyFromUrl for same-account copies. SAS token generation covers both blob-level (e.g. read-only) and container-level (e.g. read+list) permissions with an expiry. Blob properties (size, content type, last modified) and custom metadata/HTTP headers can be read and set independently of the blob's content. Leasing (BlobLeaseClient) covers acquiring a lease for a duration (or infinite), renewing it, and releasing it, for coordinating exclusive access. Error handling catches BlobStorageException for status code and error code, calling out 404 (blob not found) and 409 (conflict, e.g. an active lease). A proxy configuration example wires an HTTP proxy into the client's underlying Netty HTTP client.

Use this skill when building a Java application that stores, retrieves, lists, or manages access to unstructured blob data in Azure Storage - file uploads/downloads, streaming large files, generating time-limited shareable links via SAS, or coordinating exclusive access with leases. It is not for hierarchical file-system semantics with POSIX-style ACLs and directory rename (that's Azure Data Lake Storage Gen2's dedicated SDK) - this is flat object storage with prefix-based virtual directories only.

Input is blob names/paths, data to upload (string, file, stream, or byte payload) with optional headers/metadata, or SAS/lease parameters. Output is uploaded/downloaded blob content, listed BlobItems (flat or hierarchical), generated SAS tokens, and lease IDs for exclusive access coordination.

Built on the Azure Storage Blob Java SDK (azure-storage-blob), authenticated via SAS token, connection string, or DefaultAzureCredential, with optional HTTP proxy configuration via Netty.

<dependency>
    <groupId>com.azure</groupId>
    <artifactId>azure-storage-blob</artifactId>
    <version>12.33.0</version>
</dependency>

Java developers building applications that store and serve unstructured blob data in Azure Storage - file uploads/downloads, streaming, shareable SAS links, and exclusive-access coordination via leases.