First, a little bit of context. I took on a little task in my team recently and I thought it would be great to share the steps with other junior developers who might be in the same spot.

We have an application that runs on a distributed microservice architecture and these were the conditions I worked under:

• 35 repositories in scope.
• Thorough and smooth code review process having at least 2 team members approving my pull request before mergeing the change to main.
• Bitbucket's and JIRA's integrated solution for smooth version control. Really nice to keep the structure when creating 35 branches and opening 35 pull requests ;)

Run Before & After Snap-shots

The main approach for this upgrade task is pretty simple. You run a code inspection using your current Java version and then you run the same code inspection using the new version.

But before you start make sure you have the Java17 JDK installed on your local machine. Either you have the package installed and ordered through your organisations enterprise solution or you can find it here.

Also make sure you are running your inspection with the right JDK. See below screen-print. You point to the correct version by going into File > Project Structure.

After applying your "old" Java version and selecting OK you can start your code inspection.

Run code inspection

You choose Code in the main menu and by selecting "Inspect Code" you move on to selecting the level you want to run the inspection on.

We want to review the whole project/repository.

Review results

After IntelliJ has gone through your project you are going to get a complete overview of the result, as below.

In this walk-through we consider the warnings as a snapshot on what IntelliJ has found without fixing the related code. We save them for refactoring work in another task. We want to focus on the Java17 upgrade and keep our branch clean.

After confirming how many warnings and what type of warnings there are, we proceed with updating the project structure with the latest Java version. Java17 in this example.

Update Project Structure & Re-Run Code Inspection

Assuming you already have the latest JDK installed on your machine we can now apply the Java17 package. We perform the same code inspection and review steps as above.

Reviewing the results after code inspection, with exactly the same result.

This means there are not any Java17 updates we need to change in our code this time.  As mentioned, we treat these warnings as refactoring tasks in upcoming work.

We are now approaching the final steps and we need to update the Project Object Model (also known as POM) so that the project can be built successfully.

Updating the Project Object Model.

The Project Object Model needs to be updated with the latest version references to clarify which Java version this project is built/updated upon.

Two easy steps to complete:

1. In the properties section, make sure to update the java version to the correct one, after verifying that the unit tests and builds are successful.
2. Make sure to update the requireJavaVersion section in the pom.xml to notify developers on what SDK is required.

<properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
        <java.version>17</java.version>
    </properties>

<requireJavaVersion>
         <message>
             You are running an older version of Java. Project requires at least JDK 17.
         </message>
	<version>[${java.version},)</version>
</requireJavaVersion>

Don't Push It...Yet

Now when we are approaching the end of this task we don't want to forget to commit and push our changes to our branch, but don't forget to run your tests and make sure the project builds successfully.

Run Application (shift+F10)

Build Project (ctrl+F9)

Completed!

Congratulations! You have now run through your repository and made sure it is updated according to the latest Java17 standard.

Wrapping Up & Something to think about...

Finally I have some thoughts I wanted to share that popped up during my process of updating all the 35 repositories.

Are you having an automated deployment pipeline?

As we are using Maven to streamline dependencies and builds for our Java projects I realised the installed version needs to be updated as well. Plus, having automated deployment builds require may mean that your builds would fail if you have a discrepancy between versions.

What I learned was that if you use Jenkins Servers they need to have the correct Maven versions installed as well.

Nothing wrong keeping the PR's small.

Keeping your PR's small is not a bad thing. I accidently bumped into some bug fixes and refactoring while doing this task. That created some confusion in my pull requests.

Keeping the branch clean and focused on your task at hand makes it much easier and faster to have your pull request approved.

One PR for multiple repo's?

While doing trivial updates like this, I stumbled upon an idea of the possibility to commit and push all your changes (since they are very much similar) into multiple branches. Instead of creating one PR per repository (35 in my case).

This is possible if you are working in a mono-repo but technically not possible when you are working in a microservice architecture where the repositories are "disconnected" from each other. This is of course a chosen strategy to mitigate the risk of having one change that would affect code that it is not even related to.

It appears I wasn't the first one thinking about this.

It would be interesting to see whether this is possible in the future though. Having the benefits of separated repo's but having the smooth benefit of pushing your changes fewer times...

If you found any steps missing in this process, do let me know in the comments below. Or if there are any smoother way to perform this update we would gladly receive those advice!