# AWS SDK for Java 1.x after end-of-support: what still works and what to verify > The 1.x line of the official AWS SDK for Java stopped receiving updates on 2025-12-31. This is what the repository still gives you, how the Maven BOM install works, and where the migration to 2.x actually bites. **aws/aws-sdk-java** — The official AWS SDK for Java 1.x (In Maintenance Mode, End-of-Life on 12/31/2025). The AWS SDK for Java 2.x is available here: https://github.com/aws/aws-sdk-java-v2/ - Repository: https://github.com/aws/aws-sdk-java - Website: https://aws.amazon.com/sdkforjava - Stars: 4,201 · Forks: 2,778 - Language: Java - License: Apache-2.0 - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/aws-aws-sdk-java ## What the 1.x SDK is for, and who it still serves This repository is the official AWS SDK for Java 1.x: a set of Maven artifacts under the com.amazonaws groupId that let Java code call AWS services such as Amazon S3, DynamoDB and Glacier from a single dependency tree. The README states plainly that the SDK reached end-of-support on December 31, 2025, that it no longer receives updates or releases, and that previously published releases stay available through public package managers while the code remains on GitHub. The last push to the repository was on 2026-04-06, so the tree is not frozen in place, but the README's own framing is the one that matters: no updates, no releases. The audience is therefore narrow and specific. It is teams with running Java services that already compile against com.amazonaws artifacts and need them to keep compiling. It is also anyone maintaining a library that exposes 1.x types in its public API, which makes a version switch a breaking change for downstream consumers. It is not a sensible starting point for new code. The README opens by pointing readers to the 2.x repository for getting started, and repeats that recommendation in the maintenance-mode section. ## Per-service modules and the BOM: how the 1.x layout works The repository is not one library. The top-level listing is dominated by directories named aws-java-sdk-, one per AWS service, from aws-java-sdk-accessanalyzer and aws-java-sdk-account through to the services further down the alphabetical list. Alongside them sits aws-java-sdk-bom, the bill of materials, plus aggregate modules such as aws-java-sdk-bundle. That structure is the whole design: you depend on the service clients you need rather than pulling every client into your classpath. The BOM is what keeps those per-service artifacts on one version. You import it in dependencyManagement, then declare individual modules in dependencies without a version element, and Maven resolves each one to the version the BOM pins. This is the mechanism that prevents a mixed-version classpath, where aws-java-sdk-s3 and aws-java-sdk-dynamodb come from different releases and share transitive dependencies that may not agree. The README shows exactly this two-step pattern, and the version it prints in the BOM example is 1.12.797. The SDK requires Java 1.8 or later. The README also states that 1.x supports Java versions from 8 to 17 but may not be updated to support future Java versions, which is the concrete reason a team on a newer JDK has to think about this now rather than later. ## Installing 1.x from Maven and making a first S3 call Add the BOM first. This block goes inside dependencyManagement and fixes the version for every com.amazonaws artifact you declare afterwards; the README uses 1.12.797 in its example, and you should pin whatever version you have validated rather than letting it float. ```xml com.amazonaws aws-java-sdk-bom 1.12.797 pom import ``` Then declare only the clients your code uses. The README's example lists EC2, S3 and DynamoDB, and the absence of a version on each entry is the point: the BOM supplies it. ```xml com.amazonaws aws-java-sdk-s3 ``` After a Maven resolve, the aws-java-sdk-s3 jar and its transitive dependencies should appear in your local repository at the BOM's version. A first call follows the 1.x client pattern: build an AmazonS3 client, then call an operation on it. The README does not include a code sample for this, so follow the 1.x developer guide linked from the repository rather than inventing a builder chain. If you build the SDK itself from a checkout, the README gives one command and notes that it disables GPG signing: ```bash mvn clean install -Dgpg.skip=true ``` ## The end-of-support boundary is the real limitation The failure mode here is not a crash. It is drift. The SDK no longer receives updates or releases, so a new AWS service, a new API operation, or a change in how an existing service behaves will not appear in a 1.x artifact. If your integration depends on a service surface that postdates the final 1.x release, the 1.x client simply has no method for it and no future release will add one. That is a hard boundary, not a temporary gap. The README also flags a second constraint: 1.x supports Java 8 through 17 but may not be updated for future Java versions. A team that plans to move to a newer JDK is planning a move off 1.x at the same time, whether or not it says so. The wrong-tool case is any greenfield service, and any workload that needs features the README attributes to 2.x: non-blocking I/O, automatic iteration over paginated responses, and the ability to plug in a different HTTP implementation at run time. If you need any of those, 1.x is the wrong choice regardless of how stable it looks. Pinning to a final 1.x version keeps an existing service building, and that is the extent of what it buys you. ## AWS SDK for Java 2.x versus 1.x: a different code base, not a version bump The README describes 2.x as a major rewrite of the 1.x code base, built on Java 8 or later. The differences it names are architectural rather than cosmetic: non-blocking I/O, improved start-up performance, automatic iteration over paginated responses, and a pluggable HTTP implementation at run time. None of those can be reached by changing a version number in a 1.x BOM, because they are properties of the client design. That is the practical difference in approach. A 1.x migration within the line is a dependency edit; a move to 2.x is a code migration, since client construction and request types differ between the two code bases. The README points to a migration guide for that work and to the 2.x developer guide for the target API. If you are choosing between the two for new work, the choice is already made in the README's own text, which directs readers to 2.x for getting started and recommends migrating. ## Maintenance cost, licence and what the repository still carries The maintenance cost of staying on 1.x is the cost of owning the gap yourself. Because the SDK no longer receives updates or releases, any fix to a 1.x client has to come from your fork or your own patch, and the README's build command (mvn clean install -Dgpg.skip=true) is the entry point for that. Budget for it explicitly rather than assuming a dependency bump will arrive. The licence is Apache-2.0, per the repository's LICENSE.txt and the SDK licence link in the README. That permits commercial and closed-source use, and it is also what allows a team to fork and patch the code if a 1.x fix is genuinely needed. This is a description of the licence, not legal advice; check your own obligations around NOTICE.txt and attribution with whoever handles that for your organisation. Upgrade cost depends on how much of the 1.x surface you touch. A service that uses one or two clients and simple request types is a contained change. A service that wraps 1.x types in its own public interfaces is a larger one, because every consumer of those interfaces inherits the migration. ## Conclusion Adopt 1.x only to keep an existing Java 8 to 17 service building while you plan the 2.x migration, and pin the BOM version in your own dependencyManagement rather than trusting a floating range. Do not start a new project on it: the SDK no longer receives updates or releases, and no dependency bump will change that. Before migrating, verify two things in your own tree: which com.amazonaws artifacts you actually resolve, and whether anything depends on client construction or request types that 2.x changed. The migration guide linked from the README is the starting point, not the whole job. ## FAQ ### Is the AWS SDK for Java 1.x deprecated? The README states that the SDK reached end-of-support on December 31, 2025, and that it no longer receives updates or releases. Previously published releases remain available through public package managers, and the code stays on GitHub. ### What is the AWS SDK for Java? It is the official AWS SDK for Java 1.x, a set of Maven artifacts under the com.amazonaws groupId that let Java code work with AWS services including Amazon S3, DynamoDB and Glacier. The repository is organised as per-service modules plus a bill of materials. ### How do I install the AWS SDK for Java 1.x with Maven? Import com.amazonaws:aws-java-sdk-bom with type pom and scope import inside dependencyManagement, then declare the per-service modules you need in dependencies without a version element. The README's BOM example uses version 1.12.797. ## Sources - [aws/aws-sdk-java on GitHub](https://github.com/aws/aws-sdk-java) - [Issues](https://github.com/aws/aws-sdk-java/issues) - [License: Apache-2.0](https://github.com/aws/aws-sdk-java/blob/master/LICENSE) - [Project website](https://aws.amazon.com/sdkforjava) - [README](https://github.com/aws/aws-sdk-java/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/aws-aws-sdk-java