Java code transformation using the Amazon Q Developer GitHub Integration

AWS have launched the Amazon Q Developer integration with GitHub. I was keen to try this out, and in this post, I walk through how to get started and use the integration to upgrade a Java project. Getting Setup The first step is to install the Amazon Q Developer application from the GitHub Marketplace found at this URL - https://github.com/apps/amazon-q-developer. Then click on Install and select which repositories you want to allow the application to access. You can also optionally register the application installation with your AWS account to increase your usage limits. This is a two-step process. A landing page in your AWS console allows you to authorise Amazon Q Developer to access your GitHub account. This redirects you to GitHub to complete the authorisation process. You are then returned the AWS Console to provide a registration name and complete the registration process. Setup GitHub Actions Before you can get started on running a transformation request, you need to enable GitHub Actions for the repository and ensure a runner is available online. This involves creating a main.yml file within a .github/workflows/ folder structure. The workflow I used is shown below: name: Q Code Transformation on: push: branches: - 'Q-TRANSFORM-issue-' env: MAVEN_CLI_OPTS: >- -Djava.version=${{ contains(github.event.head_commit.message, 'Code transformation completed') && '17' || '11' }} jobs: q-code-transformation: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - uses: actions/setup-java@v3 with: java-version: ${{ contains(github.event.head_commit.message, 'Code transformation completed') && '17' || '11' }} distribution: 'adopt' - name: Build and copy dependencies run: | mvn ${{ env.MAVEN_CLI_OPTS }} clean install -U mvn ${{ env.MAVEN_CLI_OPTS }} verify mvn ${{ env.MAVEN_CLI_OPTS }} dependency:copy-dependencies -DoutputDirectory=dependencies -Dmdep.useRepositoryLayout=true -Dmdep.copyPom=true -Dmdep.addParentPoms=true - name: Upload artifacts uses: actions/upload-artifact@v4 with: name: q-code-transformation-dependencies path: dependencies This creates a workflow named Q Code Transformation that is triggered when code is pushed to a branch that matches the pattern Q-TRANSFORM-issue-. The job itself runs on Ubuntu, and starts by checking out the code in the repository into the GitHub Action runner. It then installs and sets up a Java installation using the AdoptOpenJDK distribution on the runner. The choice of Java version is chosen dynamically. If the commit message contains "Code transformation completed", Java version 17 is installed, else Java 11. The script then uses maven commands to clean and rebuild the project, builds the projects and runs all tests, and finally copies all project dependencies into a specific folder. These are then uploaded as a project artifact from the runner machine into GitHub. Triggering the Code Transformation Triggering the Java code transformation is as simple as raising a GitHub issue, and applying the Amazon Q transform agent label to the issue. The amazon-q-developer application then takes over, adding comments to the issue to keep you up to date. It starts by running the GitHub Actions workflow required to transform the code. You can view the progress of the runner in the Actions tab. Once successful, your code to be transformed is uploaded, and a transformation plan created. This code transformation plan sets out the changes that the agent is initially expecting to apply. The agent then starts upgrading the code to Java 17. Once complete, the agent updates the issue with a comment and opens a pull request. Viewing the transformed code The pull request opened by the agent starts off with a code transformation summary detailing the changes made during the transformation process. One area that the transform agent has significantly improved over the past few months is in summarising these changes. Not only are these nicely laid out in a list format, but for each significant change, there are details provided why it has been made and the benefits it offers. Security vulnerabilities and code quality issues One benefit that the GitHub integration brings is the scanning of all pull requests for security vulnerabilities and code quality issues. The application will raise a comment in the pull request, and then highlight any findings it discovers. In my case, the application generates a high severity warning. For each vulnerability found, a detailed description of the fix needed alongside code that can be committed is provided. If multiple issues are discovered, you can go into the Files Changed and select to batch up all of the suggestions into a single commit. Observations and Conclusion There are

May 6, 2025 - 11:38

Java code transformation using the Amazon Q Developer GitHub Integration

AWS have launched the Amazon Q Developer integration with GitHub. I was keen to try this out, and in this post, I walk through how to get started and use the integration to upgrade a Java project.

Getting Setup

The first step is to install the Amazon Q Developer application from the GitHub Marketplace found at this URL - https://github.com/apps/amazon-q-developer.

Then click on Install and select which repositories you want to allow the application to access.

You can also optionally register the application installation with your AWS account to increase your usage limits. This is a two-step process. A landing page in your AWS console allows you to authorise Amazon Q Developer to access your GitHub account.

This redirects you to GitHub to complete the authorisation process.

You are then returned the AWS Console to provide a registration name and complete the registration process.

Setup GitHub Actions

Before you can get started on running a transformation request, you need to enable GitHub Actions for the repository and ensure a runner is available online.

This involves creating a main.yml file within a .github/workflows/ folder structure. The workflow I used is shown below:

name: Q Code Transformation

on:
  push:
    branches:
      - 'Q-TRANSFORM-issue-*'

env:
   MAVEN_CLI_OPTS: >-
     -Djava.version=${{ contains(github.event.head_commit.message, 'Code transformation completed') &&  '17' || '11' }}

jobs:
  q-code-transformation:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-java@v3
        with:
          java-version: ${{ contains(github.event.head_commit.message, 'Code transformation completed') && '17' || '11' }}
          distribution: 'adopt'

      - name: Build and copy dependencies
        run: |
          mvn ${{ env.MAVEN_CLI_OPTS }} clean install -U
          mvn ${{ env.MAVEN_CLI_OPTS }} verify
          mvn ${{ env.MAVEN_CLI_OPTS }} dependency:copy-dependencies -DoutputDirectory=dependencies -Dmdep.useRepositoryLayout=true -Dmdep.copyPom=true -Dmdep.addParentPoms=true

      - name: Upload artifacts
        uses: actions/upload-artifact@v4
        with:
          name: q-code-transformation-dependencies
          path: dependencies

This creates a workflow named Q Code Transformation that is triggered when code is pushed to a branch that matches the pattern Q-TRANSFORM-issue-*. The job itself runs on Ubuntu, and starts by checking out the code in the repository into the GitHub Action runner.

It then installs and sets up a Java installation using the AdoptOpenJDK distribution on the runner. The choice of Java version is chosen dynamically. If the commit message contains "Code transformation completed", Java version 17 is installed, else Java 11.

The script then uses maven commands to clean and rebuild the project, builds the projects and runs all tests, and finally copies all project dependencies into a specific folder. These are then uploaded as a project artifact from the runner machine into GitHub.

Triggering the Code Transformation

Triggering the Java code transformation is as simple as raising a GitHub issue, and applying the Amazon Q transform agent label to the issue.

The amazon-q-developer application then takes over, adding comments to the issue to keep you up to date. It starts by running the GitHub Actions workflow required to transform the code. You can view the progress of the runner in the Actions tab.

Once successful, your code to be transformed is uploaded, and a transformation plan created. This code transformation plan sets out the changes that the agent is initially expecting to apply.

The agent then starts upgrading the code to Java 17. Once complete, the agent updates the issue with a comment and opens a pull request.

Viewing the transformed code

The pull request opened by the agent starts off with a code transformation summary detailing the changes made during the transformation process.

One area that the transform agent has significantly improved over the past few months is in summarising these changes. Not only are these nicely laid out in a list format, but for each significant change, there are details provided why it has been made and the benefits it offers.

Security vulnerabilities and code quality issues

One benefit that the GitHub integration brings is the scanning of all pull requests for security vulnerabilities and code quality issues. The application will raise a comment in the pull request, and then highlight any findings it discovers. In my case, the application generates a high severity warning.

For each vulnerability found, a detailed description of the fix needed alongside code that can be committed is provided.

If multiple issues are discovered, you can go into the Files Changed and select to batch up all of the suggestions into a single commit.

Observations and Conclusion

There are a few areas that are worth drawing out that initially caught me out.

Supported Target Code Versions
The transform agent in the IDE currently only supports Java 17. The transform agent in the IDE has recently enabled support for Java 21 as a target code version as well as Java 17.
Code Review
The code review run on the pull request is only carried out against the changes made in the diff, and not against unchanged content in these files, or the entire repo. To do this, you will need to go back to the IDE and run the /review agent. It would be great to trigger a full code review on an entire repo through the GitHub integration
Code Suggestions for Security Vulnerabilities
Ironically, as the code review is only carried out against new changes, the vulnerability detected by the agent is against code that the agent itself created. I'm not entirely sure how I'm supposed to feel about this. In fairness, its most likely a reflection of the wider codebase and the code suggestion following the existing styling. In addition, the code suggestion made to resolve the security vulnerability which I automatically accepted failed compilation. This was detected almost straight away as it triggered another run of the GitHub Action. It turned out simpler to fix this compilation error manually and add this as a commit to the pull request. I'm not sure why this was the case, but I feel confident this will be fixed soon.

For Java transformations this now provides an alternative approach to using the agent in the IDE. Using the transform agent in the IDE feels more synchronous, as you watch the progress taking place in the Transformation Hub terminal. I really enjoyed the asynchronous nature of the GitHub integration. I can simply create a new issue, use a label to assign to the transform agent, and then wait for the email notification that it is complete. This frees up time to carry on with other value add activities.

Running the transform agent in the IDE, you are also responsible for creating a separate branch, committing the changes to this branch, and raising the PR, all of which is taken care of for you with the GitHub integration. Even better, once merged into the main branch, the full conversation history is still maintained in the closed Pull Request for transparency.

The project I used can be found here - https://github.com/mlewis7127/bicycle-licence-GH-integration. If you have a requirement to transform old Java code projects, I would definitely recommend checking out this integration, and see how it fits into your developer workflow.