Context
The hardwood-s3 module currently depends on software.amazon.awssdk:s3, which pulls in 31 transitive JARs totaling ~8 MB. The S3 service client JAR alone is 4 MB. Yet we use exactly 4 types from the SDK:
S3Client.getObjectAsBytes() — HTTP GET with Range headerGetObjectResponse — to read Content-RangeResponseBytes — to get the response bodyS3Exception — error handling
The actual I/O is two HTTP operations: a suffix-range GET (for open()) and byte-range GETs (for readRange()). Both are simple HTTP GETs with SigV4 signing.
Options
| Approach |
Deps |
Credential chain |
Effort |
Status quo (aws-sdk:s3) |
8 MB / 31 JARs |
Full |
Done |
aws-sdk:auth + JDK HttpClient |
~2 MB / ~10 JARs |
Full |
Medium |
| Pure JDK, env/profile credentials only |
0 extra |
Partial (no IMDS/ECS) |
Medium |
| Pure JDK, full credential chain |
0 extra |
Full |
Large |
Recommended exploration: aws-sdk:auth + JDK HttpClient
Keep the AWS SDK's auth and regions modules for credential resolution and SigV4 signing, but replace the S3 service client with direct HTTP calls via java.net.http.HttpClient. This would:
- Drop ~6 MB of dependencies (S3 service client, XML/query protocols, checksums, retries, eventstream)
- Keep the full credential provider chain (env vars, profiles, IMDS, ECS, web identity)
- Align with Hardwood's minimal-dependency philosophy
The implementation would be a small HTTP wrapper that:
- Resolves credentials via
AwsCredentialsProvider
- Signs requests with SigV4 (
Aws4Signer or the newer AwsV4HttpSigner)
- Sends GET requests with
Range headers via java.net.http.HttpClient
- Parses
Content-Range from responses
Alternative: pure JDK
If we're willing to limit credential support to environment variables, system properties, and AWS profile files (covering ~90% of real-world usage outside containers), we could implement SigV4 signing directly (~200-300 lines) and have zero external dependencies. EC2/ECS instance metadata (IMDS) is the part that makes a full from-scratch implementation painful.
Context
The
hardwood-s3module currently depends onsoftware.amazon.awssdk:s3, which pulls in 31 transitive JARs totaling ~8 MB. The S3 service client JAR alone is 4 MB. Yet we use exactly 4 types from the SDK:S3Client.getObjectAsBytes()— HTTP GET withRangeheaderGetObjectResponse— to readContent-RangeResponseBytes— to get the response bodyS3Exception— error handlingThe actual I/O is two HTTP operations: a suffix-range GET (for
open()) and byte-range GETs (forreadRange()). Both are simple HTTP GETs with SigV4 signing.Options
aws-sdk:s3)aws-sdk:auth+ JDK HttpClientRecommended exploration:
aws-sdk:auth+ JDK HttpClientKeep the AWS SDK's
authandregionsmodules for credential resolution and SigV4 signing, but replace the S3 service client with direct HTTP calls viajava.net.http.HttpClient. This would:The implementation would be a small HTTP wrapper that:
AwsCredentialsProviderAws4Signeror the newerAwsV4HttpSigner)Rangeheaders viajava.net.http.HttpClientContent-Rangefrom responsesAlternative: pure JDK
If we're willing to limit credential support to environment variables, system properties, and AWS profile files (covering ~90% of real-world usage outside containers), we could implement SigV4 signing directly (~200-300 lines) and have zero external dependencies. EC2/ECS instance metadata (IMDS) is the part that makes a full from-scratch implementation painful.