Amazon Q Developer Agent for Code Transformation

Background

Here in the UK, the

All too often, all engineering effort is spent building new features, and existing applications are left untouched, until they are running out of date versions of libraries and frameworks with all kinds of inherent vulnerabilities. This is where the Amazon Q Developer Agent for Code Transformation comes into its own. In this article, we take the agent for a spin looking to upgrade a Java 11 application to Java 17.

Bicycle Licence Application

In March 2020, I presented an online AWS tech talk demonstrating features of Amazon QLDB in an application written in Java 11 and Spring Boot. In the past couple of months, I have replaced Amazon QLDB with Amazon DynamoDB, and made sure that it is simple to start up and run as a Java 11 application. This is now a great project to test out the code transformation agent. It is a more complex application with around 750 lines of code than a basic "Hello World" application, but not so large it is difficult to understand. You can clone this project yourself

The application requires a DynamoDB table with a Global Secondary Index to be setup in the eu-west-1 region, and there is a CloudFormation template provided you can use to set this up. I couldn't remember the exact command to use, but luckily Amazon Q on the command line came to the rescue.

Creating a new Bicycle Licence record

Once launched, the application will be running at http://localhost:8080/. Opening this in a browser window will render the landing page for the application:

Once created, you can go into the view/update licence tab and add some points to the licence:

Now we have this up and running as a Java 11 application, we want to look to migrate to Java 17.

Running the code transformation agent

The first step in running a code transformation is to type /transform into the Amazon Q chat window.

There is also an option for the agent to build your module with or without running unit tests. The default is to run tests, and a number of unit tests are included as part of the project to show this feature working.

The first step is that Amazon Q builds your module locally, downloading all dependencies, and then running the unit tests. Assuming this is successful, Amazon Q will then scan the project files and get ready to start the job. To do this, the project artifacts are uploaded to a managed secure build environment on AWS.

Once the files have been uploaded, the transformation job has been accepted and is ready to start. The application is built again using Java 11. Following this, the code is analysed in order to generate a transformation plan.

After just over 12 minutes, the transformation job was complete, and it was time to review the code diff and see the proposed changes:

You can click on each one, to see these changes. In the example below, we can see that a new method has been added to the BicycleLicenceDynamoDBRepository.java class. This is because the CrudRepository interface provided by Spring Data that this class implements has had this new method added to it in the version upgrade.

We are now in a position where we can test the application after it has been transformed to Java 17. After accepting the code changes, we run an mvn clean and mvn compile and reload all project dependencies. It also involves making sure the project structure is setup to use version 17 of the Java SDK, alongside the Run Configuration.

Running the Java 17 application

After making the previous changes, we run the application and can interact with the bicycle licence with no issues. However, one thing we notice is a warning message in the console that the AWS SDK for Java 1.x has entered maintenance mode and will reach end of support on December 31, 2025.

I really liked the fact that the developer agent created a migration plan which it then used iteratively to update all dependencies. This was a markdown file as shown below:

Although the developer agent came up with a large number of correct changes, there were still some errors left behind. This really helped to highlight the differences between the two agents currently available. The two key points for me are:

• The software development agent does not allow you to test the generated code before it is accepted. This means that any issues such as compilation errors will need to be fixed manually (supported by the chat interface), or thrown back to the agent consuming another code generation from your quota


• The code transformation agent uploads your artifacts to a secure build environment, and will continually try to build and compile your code, fixing any errors as it goes along, until it is complete.

Conclusion

The Amazon Q Developer Agent for code transformation is a great example of the value that agents can bring, and why I believe they are the future for coding assistants. It handles the complex task of upgrading an application from an older version to a newer version autonomously, significantly reducing developer effort.

The two main drawbacks I encountered are:

• The agent did not look to transform the outdated AWS SDK for Java 1.x libraries to the latest AWS SDK for Java 2.x libraries


• The target version is currently at Java 17. This is now outdated itself. Amazon Corretto 17 was released in September 2021, whilst Amazon Corretto 21 was released in September 2023 and Amazon Corretto 23 was released in September 2024, and hopefully we will see these more recent versions supported shortly.

Nevertheless, I really hope you try this agent out for yourself, and I'd love to hear your feedback.