Java in AWS with Wojtek Gawroński - JVM Weekly vol. 126
I'm experimental mood recently, so today, we have the interview!
There is a Polish context for today’s edition. One of my favorite podcasts is Patoarchitekci, where Łukasz Kałużny and Szymon Warda discuss all things interesting in the world of cloud and broadly understood architecture. Recently (ok, not that recently - in January), they invited Wojtek Gawroński, Senior Developer Advocate at AWS, to explain a few things about the JVM and AWS.
While listening to that episode, I thought the relationship between AWS and the JDK is so interesting that it’s worth exploring in JVM Weekly. Wojtek (whom I met at 4Developers conference) agreed to answer my questions, which resulted in the very first interview in our newsletter’s history.
Enjoy the read!
Artur Skowroński: Thanks for joining me today, Wojtek. After listening to your discussion on the Patoarchitekci podcast (episode 139), podcast, I thought it would be great to dive deeper into Amazon and AWS's contributions to the open-source JVM ecosystem. Let's start with the basics: when did Amazon begin actively contributing to OpenJDK?
Wojtek Gawroński: Thank you for having me, Artur. Many people don't realize that Amazon and AWS have been deeply involved with the OpenJDK community for quite some time. We've been a voting member of the OpenJDK Governing Board since 2017, which allows us to have input on the project's direction and stewardship. However, our work with Java goes back much further, as we've been running Java at massive scale across thousands of production services, including high-traffic platforms like Amazon.com and various AWS services.
Artur: I assume most Java developers (and for sure those reading this newsletter) have already heard about Amazon Corretto, but can you explain what motivated Amazon to create its own OpenJDK distribution in an already crowded market? Involvement in Java is one thing, but I wonder why your distribution?
Wojtek: We launched Amazon Corretto in 2018 as a response to numerous questions from our customers about how we handle JVM-based applications internally at scale. As a company that heavily relies on Java, we wanted to ensure there would be a no-cost, production-ready distribution of OpenJDK with long-term support.
Corretto is certified against the Java SE standard using the Technology Compatibility Kit (TCK), so it's completely compatible with existing Java applications. What's particularly important is that Corretto is distributed under the GNU GPLv2 license with the Classpath Exception, ensuring no hidden costs or restrictions for users.
Artur: Got it! So essentially, you wanted to reassure all the folks running on AWS that there's a Java distribution they can safely use in the clouds. But just to follow up on that—what platforms does Corretto support, and how long can users count on getting updates? Do you still support JDK 1.8?
Wojtek: Corretto supports all the major platforms: Linux (both x86_64 and ARM64 architectures), Windows, macOS, and even Alpine Linux. We also provide Docker images via Amazon ECR Public Gallery and Docker Hub. Regarding support, we've made a strong commitment to long-term support. We guarantee free security updates and performance enhancements for Java 1.8, 11, 17, 21, and 23 until at least 2030. That's much longer than many other distributions, giving organizations the stability they need for planning their Java infrastructure.
Artur: So yeah… looks like JDK 1.8 is here to stay—at least partly thanks to you folks at Amazon, right? 😄
Wojtek: Yeah, kinda sorry-not-sorry, especially, as it's unsurprising - how predominant still 1.8 is in the field.
Artur: But beyond the long-term support, what would you say really sets Corretto apart from other OpenJDK distributions?
Wojtek: I think the key differentiator is that Amazon actually runs Corretto internally on thousands of production services. This real-world validation at enormous scale ensures that Corretto's patches address performance bottlenecks, memory management issues, and security vulnerabilities that are genuinely encountered in production environments.
We provide quarterly updates that include backported fixes from newer OpenJDK versions as well as Amazon-specific optimizations, particularly in areas like garbage collection and thread management. For example, our latest quarterly updates (Corretto 23.0.2, 21.0.6, etc.) included critical security patches and stability improvements.
Artur: Ok, now it’s getting interesting—we’re getting to the good stuff. Let’s talk about the performance side of things. Has Amazon contributed any effective optimizations to the JVM through Corretto? Any real-world examples you can share?
Wojtek: One standout innovation is the Amazon Corretto Crypto Provider, or ACCP. It replaces the default Java cryptographic implementations with highly optimized versions that leverage OpenSSL's libcrypto. The performance improvements are substantial—up to 28x faster for operations like AES-GCM through CPU-level tuning and assembly optimizations.
This is particularly impactful for services handling encryption at scale, such as our own S3 and DynamoDB, but not limited to this, as you can read how this work helped with optimizing the performance of ARM64-based Apache Kafka deployments. And the best part is that ACCP is integrated into Corretto 8 and 11, offering these performance gains without requiring any code changes from developers.
Another great addition happened in 2021, when we announced generational mode to the Shenandoah Garbage Collector (GC). This was a result of our collaboration with Red Hat. By adding a generational mode, the Amazon Corretto team delivers the benefits of Shenandoah to a broader audience of Java developers who wish to build applications with high memory allocation rates (beyond 4 GB/s) and/or high live memory utilization (beyond 60%). With certain workloads, Shenandoah's new generational mode matches traditional Shenandoah response times using one-third the heap size and can be configured by the customer to deliver maximum GC pause latencies below 10 ms.
Another important addition was enhancements around asynchronous logging support in Corretto 17. This was a direct result of work coming from one of the AWS service teams that diagnosed unexpected GC pauses, and the Corretto team discovered that applications were being throttled by I/O blocking while writing logs to disk. As a result, async-logging was implemented and contributed to OpenJDK 17.
Artur: Corretto’s one thing—but what about the bigger picture? How does Amazon give back to the broader OpenJDK project beyond just maintaining its own distribution? Any other project I (and readers) should be aware of?
Wojtek: We actively contribute to OpenJDK by backporting fixes from newer releases and submitting upstream enhancements. For instance, Corretto includes Amazon-specific patches informed by our operational experience running Java in distributed systems, where latency and resource efficiency are critical.
We prioritize upstreaming Corretto patches to ensure the broader ecosystem benefits. All of the fixes and features mentioned earlier—including ones related to performance improvements, garbage collection inefficiencies, and out-of-memory errors in Corretto—have been contributed back to OpenJDK.
Last, but not least, we contribute to tooling around OpenJDK, and a great example is an open-source Heapothesys benchmark, a synthetic workload that simulates fundamental application characteristics that affect GC latency. The benchmark creates and tests GC load scenarios defined by object allocation rates, heap occupancy, and JVM flags, then reports the resulting JVM pauses. OpenJDK developers can thus produce reference points to investigate capability boundaries of the technologies they are implementing.
Artur: And what about developer tooling? How does AWS support Java devs beyond just the runtime? I’ve used the AWS SDK for Java—and even Kotlin—a bunch of times myself, but there is far more for sure.
Wojtek: We've invested significantly in tools like the AWS SDK for Java. Version 2.x is a complete non-blocking, modular rewrite designed for modern Java applications. It supports Java 8 and newer, and integrates seamlessly with Corretto, enabling developers to interact with AWS services like S3, EC2, and DynamoDB.
The SDK's asynchronous I/O model reduces resource contention in microservices architectures, aligning with cloud-native best practices. It provides HTTP/2 support as a pluggable HTTP layer, and we also provide comprehensive documentation, tutorials, and CI/CD pipeline examples to lower the barrier to Java adoption. For instance, we publish patterns like Automatically Build and Deploy a Java Application to Amazon EKS, which demonstrates DevSecOps practices using Corretto and Maven.
Java is truly a first-class citizen throughout the AWS ecosystem. Beyond the AWS SDK for Java that I mentioned earlier, which now has v2 with a complete redesign, we ensure Java code examples are prominently featured in our documentation. If you look at the Amazon Bedrock documentation page, for example, you'll see Java examples front and center.
Java is also fully supported in our development tools like AWS CDK (Cloud Development Kit), which lets developers define cloud infrastructure using familiar programming languages. AWS Serverless Application Model (SAM) has excellent Java support for building serverless applications, and we created and maintain Powertools for AWS Lambda (Java), an open-source suite of unified utilities for Java-based functions, that introduces best practices and libraries around observability, metrics, and logging for serverless applications deployed on AWS Lambda.
We also have Java first-class support in other tools—a great example is open-sourced Amazon Ion, which is a richly-typed, self-describing data format (a superset of JSON) that was built with Java integration in mind. It's used throughout Amazon and externally for data interchange, and it has a fully featured Java library and client to work with since inception.
And that's not the only JVM-based language that has first-class support—in 2023, Kotlin became an officially supported language inside AWS SDK. In addition to that, many internal teams are really favoring this language—to provide just one example: the Prime Video team is adopting Kotlin motivated by higher developer satisfaction and smaller codebases produced as a result of using it.
Artur: Fun but completely useless fact: migrating from AWS SDK for Java 1.x to 2.x was the very last task I did as a single man… on the Friday before my wedding. No idea why my brain decided to keep that one filed under “core memories.” 😅
Wojtek: Thankfully, AI coding assistants like Amazon Q Developer can help you with that nowadays.
Artur: And we have the nice segway - it wouldn’t be 2025 if we didn’t talk about AI, right? 😅 I’ve been hearing a lot lately about Amazon Q Developer. How does it actually support Java developers in their day-to-day work? Anything that makes you think “ok, that’s genuinely useful”?
Wojtek: Amazon Q Developer is our AI-powered coding companion, and Java is one of the languages it fully supports as a first-class citizen. What's particularly exciting are the code transformation capabilities for Java applications.
Q Developer can assist with runtime upgrades, dependency version updates, and even handle in-code transformations like converting embedded SQL from Oracle to PostgreSQL flavor. These transformations are available in popular Java IDEs including Visual Studio Code and JetBrains-based IDEs like IntelliJ—and you can read more about it here.
What's interesting is that under the hood, alongside an AI-powered engine, it leverages OpenRewrite, an open-source tool for mass refactoring of Java source code. The team responsible for this tool contributed improvements back to the OpenRewrite project as well. Developers can read more about this in one of those blog posts: Upgrade your Java applications with Amazon Q Code Transformation or The silver bullet for improving developer productivity and creativity: Eliminate technical debt at scale.
Artur: Damn, OpenRewrite again. These folks are everywhere—it’s basically a running gag at this point. 😄 But hey, let’s come back down to earth and talk serverless for a minute.
AWS Lambda dropped in 2014, and Java support followed a year later. Since then, one of the longest-running gripes with JVM-based functions has been cold starts. You know it, I know it, we’ve all felt the pain. But then came 2022 - and with it, AWS Lambda SnapStart. I still remember writing one of my newsletter favourite editions about it at the time, thinking: "Wait, this might actually change the game." And it kinda did.
So here’s my question: How does SnapStart tie back into the OpenJDK ecosystem? What's happening under the hood that makes this possible?
Wojtek: AWS Lambda SnapStart is essentially a successful productionization of the Coordinated Restore at Checkpoint (CRaC) OpenJDK standard at scale. CRaC is a project that focuses on researching coordination of Java programs with mechanisms to checkpoint (make an image of, snapshot) a Java instance while it is executing. AWS has been a pivotal contributor to the CRaC project, which addresses the notorious cold start problem that you have mentioned, which has historically challenged Java in serverless environments.
Our engineers from the Amazon Corretto team began collaborating on CRaC in 2021, focusing specifically on optimizing it for serverless use cases. Their contributions included integrating CRaC with Firecracker, our open-sourced microVM hypervisor, and implementing security hardening to ensure snapshot encryption and isolation in multi-tenant Lambda environments.
What makes this particularly significant is that we've taken a community standard, contributed substantially to its advancement, and then built a production service that implements it at a massive scale. Lambda SnapStart has dramatically reduced cold start times for Java applications in serverless environments, making Java much more competitive in this space.
Artur: Ok, as I love runtime stuff (and I hope such details are even the reason why people read this newsletter), but let’s zoom out a bit. How is AWS getting involved with the broader Java framework ecosystem? Any contributions to popular stacks like Spring, Micronaut, or Quarkus we should know about?
Wojtek: Internally we work with Java and other JVM languages, and hundreds of our developers provide open-source contributions to major Java frameworks, including Spring Boot, Quarkus, and Micronaut. A lot of our work has centered on making these frameworks work seamlessly with AWS Lambda, Lambda SnapStart, and CRaC standardization.
It was also focused on enabling support for GraalVM-built native images in AWS Lambda runtimes, which provides another approach to reducing cold starts. Our engineers collaborate directly with framework maintainers to ensure that Java developers can achieve near-instantaneous cold starts while retaining the productivity benefits of these frameworks.
For each framework, we've developed specialized tooling and published best practices. Our future efforts will likely focus on ARM64 optimizations for these frameworks, as well as leveraging Amazon Q Developer to provide AI-driven recommendations for application priming and optimization.
Artur: What can we expect from Amazon's Java contributions in the near future?
Wojtek: We're continuing to expand Corretto's support for emerging Java features like virtual threads (Project Loom) and enhanced pattern matching. We're also refining ACCP further, with benchmarks already showing 25%+ throughput improvements in cryptographic workloads.
Looking ahead, we'll focus on tighter integration with AWS services like Lambda and Amazon Elastic Kubernetes Service (EKS), e.g., by leveraging CRaC with EKS—and in general outside of AWS Lambda environments—like explained here, while maintaining our commitment to OpenJDK stewardship. Our goal remains consistent: sustaining open-source Java ecosystems while addressing enterprise needs for stability, security, and performance at scale.
Artur: Thanks for the thoughtful answers and the peek behind the curtain. I’ve been genuinely curious about how much impact Amazon really has on the JVM landscape—nice to see it goes well beyond just maintaining your own distribution. And hey, if anything interesting comes up in the future, I hope you’ll share it with the readers!
Wojtek: It's been my pleasure, Artur. OpenJDK and the broader Java ecosystem are critical not just for AWS but for the entire industry. By providing Corretto as a free, enterprise-grade distribution and investing in security patches and optimizations like CRaC or ACCP, we're ensuring that Java remains a viable, performant platform for years to come. We're proud to be part of this community and look forward to continuing our contributions.
For more information about Amazon Corretto and AWS's Java offerings, visit https://aws.amazon.com/corretto and https://aws.amazon.com/developer/language/java.
P.S. Yeah, it’s a bit of a bummer that I feel obligated to say this, but just for the record—AWS isn’t sponsoring this edition. As I had Wojtek in my network, I simply figured: if I’m curious, maybe some of you are too.
And hey, if your company has an interesting Java story to tell, I’d be more than happy to cover it in a similar format, as long as it’s a good one. 😉
And it is always fun to have a fellow countryman as a guest in the newsletter!
 | A guest post by
|