The Java ecosystem has created a lot of very useful build tools, the most popular being Maven and Gradle. Projects using these build tools are fortunate to have a good number of plugins that enable static code analysis and other kinds of project validation. These plugins can provide great insights into issues with your project, so it is worthwhile spending time enabling these plugins and ensuring that they are configured properly.
Dependency checking
We've already spoken about using the Maven Dependency and Versions plugins for Maven in the keep our dependencies up to date best practice.
SpotBugs
SpotBugs is a great tool for finding bugs in code through static analysis. It integrates well into Maven and Gradle and can generate extremely useful reports about the quality of a codebase.
The SpotBugs project publishes short documents that detail how to integrate SpotBugs into Maven and into Gradle. Once integrated into the build process for your project, the next step is calling the appropriate build targets to generate a human-readable HTML report. Working through the reported issues will be a good learning experience for every developer about things they need to consider when coding, but it may be the case that sometimes SpotBugs will report false positives. Fortunately, these can be suppressed if they are truly incorrect, so that they do not prevent us from being 'SpotBugs-clean'.
A good goal for SpotBugs in any project is to get the codebase entirely clean of any reported issues, and once that is achieved, enable the build to fail if a SpotBugs issue is encountered. This provides protection against the code base getting worse with known issues.
CheckStyle
CheckStyle is a vastly less critical tool than SpotBugs, but it is useful in enforcing some degree of consistency of code style. It again plugs into Maven and Gradle build processes and can automatically warn via report or via build failures when the code style is no longer being adhered to. It is important to configure CheckStyle with the rules that are critical to your team, and to not just throw all available rules at it. This is because no one has fun fixing failing builds because there is a missing space between the if statement and its opening bracket, and other mostly-useless rules. It is best practice to sit the development team down together and pick out the rules that they all agree are useful, and enable only those.
JaCoCo
JaCoCo is a code-coverage tool that can visually display the amount of code that is tested by your unit tests. It helps you to identify where test coverage may be lacking, and can be used, in conjunction with Maven, to enforce a minimum level of coverage at all times.
We should not be so data-driven that we write tests purely for the sake of satisfying JaCoCo! Our goals in writing unit tests should always be to ensure correctness of our implementation, and to protect against the accidental introduction of bugs.