Amazon Q Developer Agent for Code Transformation

Background

Here in the UK, the National Cyber Security Centre (NCSC) is the 'technical authority' for cyber incidents with a view that:

patching remains the single most important thing you can do to secure your technology, and is why applying patches is often described as 'doing the basics' blog post

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 here.

Setting up the Java 11 application

All screenshots are taken using the Intellij IDEA. The first step is to clone the repository and open as a new project. Make sure the project structure is setup to use version 11 of the Java SDK:

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.

Run a mvn clean and then a mvn compile, which will compile all of the code successfully. You can then launch the application using a new Spring Boot configuration:

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:

From here, you can start by creating a new fictitious bicycle licence by specifying a name, telephone number and email address:

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

Finally, you can click in the history tab and view all the events that have taken place against that record:

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.

From here, Amazon Q will analyse the open workspace to identify if there is a module available running Java 8 or Java 11 that can be transformed. It will automatically recognise the bicycle-licence-ui module, and pre-select this for you. We can simply confirm we want to transform this module to JDK17.

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.

This is the plan used by the agent to transform your code. The whole concept of an agent is that it can run autonomously to complete a complex task, and take actions based upon its findings as it progresses, without direct human intervention. The agent can make use of RAG and custom models, which are all abstracted away from the end user. It does mean that the final code updates may end up being slightly different than the initial plan, as the agent will continue to re-evaluate its progress after each step.

The most impressive feature for me is watching the agent apply the updated dependencies and code changes, and then building the module in a Java 17 environment. You can see from the screenshot below that each time updated dependencies were added, the application failed to compile. When this took place, the agent is able to access other underlying models to work out what further changes are required, until eventually the application can now be built successfully in Java 17.

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

Clicking "view diff" opens up a new window highlighting the files that have been modified:

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.

You can also view the Code Transformation Summary provided by Amazon Q. This provides details around how many lines of code were analysed, how many files have been changed, how many planned dependencies have been added and so on. It also provides a build log summary. In this case, I can see that all source files were successfully compiled and 6 tests ran without any failures, errors or skips.

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.

In reality, it's a little disappointing that the AWS SDK library was not updated as part of the code transformation. The reality is that there are significant changes involved, and the AWS SDK for Java 2.x is a major rewrite of the 1.x code base. Out of curiosity, I wanted to see how the software development agent would handle this.

AWS SDK v1 to v2 upgrade with software development agent

With the AWS SDK for Java v1 already in maintenance mode and not updated by the code transformation agent, I wanted to see how the software development agent would handle the upgrade. I typed in \dev in the chat window, and entered the simple prompt of "Rewrite this application to use the AWS SDK for Java 2.x". The agent analysed the application and then worked through a whole set of changes

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.