 Hi everyone, I'm Brian Zemurs from Okta and today I'm going to show you five tools to help improve your Java code. This video is based on a blog post I wrote, so if you'd rather read instead of watch, I'll have the link to that and the code in the description below. Let's get started. Number one, add test coverage with Jacoco. Jacoco is my favorite Java coverage tool. It works a little different than some of the others out there, so Jacoco works with a Java agent, so you can attach it to basically any Java process. So what I've done today is I've created a little Java project and I'll be using Apache Maven because I'm a Maven fan, but all of these tools work great as well. So to add Jacoco to your project, it's just a plug-in. So if I create the plug-ins definitions here and then I've saved a little time, so you don't have to watch me type this whole thing, and I've added the plug-in block already. So in this example, I have three executions for this plug-in. So the first one is really all you need and that tells Jacoco to configure the short fire test runner to add Jacoco automatically. So that is all you need to do. If you have integration tests, which we all do, you have a similar block in Maven, integration tests are run using failsafe instead of short fire, so there's minor differences, but essentially it's the same process. And the final execution I have here is to generate an HTML report. So this could go in basically any phase, but for this example, I'm going to be using the verify phase the whole time just to keep things simple. So that's all I need to do. And if I run this example, just Maven verify, it takes a second. And there we go. So I can open the report, which is in target site Jacoco index. And here we go. So you can see this project has a couple tests. It's not great, but we can drill right down into this. So there's a hotspot right here, this file utility class, which we'll get to in a moment. And we have some utility class, which has decent coverage, but we're missing something here. So we can drill right in and see it's this add method. And we could see one of these branches is missing coverage. So you could go out of test and improve that. Number two, static analysis with PMD. PMD doesn't actually stand for anything, but it's a really great tool to help you find some common problems like unused variables, imports, empty statements. So to add PMD to a project, again, I've saved a little time here. I can remember how to type PMD. So it's worth noting that the PMD plugin is one of the official plugins that's supported by the Apache Maven team. So in this plugin, I have one execution. And I'm just going to call check, and that will do everything for me. So once again, if I run Maven Verify and run to this project, we're going to start to see that I wrote some pretty terrible code. Here we go. So we have three PMD violations. So PMD, by default, outputs to an XML file so we can crack that thing open. If I can find it. There we go, PMD, XML. So you can see that in this class file utility, I have some unused imports, an empty statement, and an unused private method. So if we head over there, you can see that. So here we go is an unused import, an empty statement. And this private method isn't actually used anywhere. You may notice some other problems with this class, but we'll get to that in a minute. Number three, byte code analysis with spot bugs and find security bugs. So if you remember, this class has a few problems, and we're going to detect those right now. So we jump back to our POM. I'm going to add a plugin for spot bugs. Now spot bugs is a great little nifty plugin that will do byte code analysis to detect similar types of problems as PMD. But you'll see it's able to detect significant issues here. So once again, I have a template to add spot bugs and just this plugin block. And I've added the find security bugs plugin within a plugin. So a plugin within a plugin. Now this one will detect security related issues. So weak hashes, untrusted imports and other common issues. And I'm basically going to fail on any type of error we see. So the threshold is low, the effort is max and fail on error is true. And we have one execution, which I'm going to just run the check goal. So once again, if I run maven verify, we're going to see some other terrible, terrible issues with this code I wrote. These will output right into the console. Here we go, four bugs. So right here we have default encoding issue. We have a missing try catch block and we have an unused private method. So if I jump back to this code, you can point that out. All right, so a couple of these can be solved with using a try with resources block or even your typical try catch and then close the stream. And we're also not setting any coding here. So typically UTF-8. So I'll leave this exercise up to you to how to clean up this code. Number four, short backwards compatibility with Java API compare. This is a great little tool I've been using for the past few years and it will detect binary source and sember compatibility issues. So typically most of the time I care about binary and sember compatibility. So I'm going to focus on that. So this also has a maven plugin and I've added this block here. So simple usage, you define the plugin and then you point to the old jar file. So in this case I'm going to use a maven dependency and almost always your group ID and your artifact ID will be the same because you're just changing versions and then you'll set the version to some previous version. Now this could be 1.0, whatever you define and type as a jar and I have some parameters here. So I only want to report on modified methods. I want to break the build if anything changes and same thing with sember. I'm going to break the build on any sember related changes. However, the Java compatibility is a little tricky. For example, adding new default methods through Java interface is technically a breaking change. Most of us will allow this and that's a great way to move your APIs forward. So you can add a post analysis script and I will create one right now. And once again, just to save time, I have a template I can use to spit out all the code so you don't have to watch me type. So this looks a little funny, it's groovy. There's a lot of other variables already in the context here. For the most part, all this is doing is it's iterating through all of the classes. Anything that has changed, so not unchanged, it's going to get all of those methods and we're going to remove any new default methods. And that way we've just excluded all of them. Number five, code reviews. Don't skip them. All of these previous tools can be added to your IDE but adding them to your build ensures they get run. It also helps make your code reviews more effective by automating all of this stuff out of them. No longer will you be asked is there a test for this, right? All of that stuff can be automatically fed into your code review. That way the human element can really shine through. The best part about code reviews is it's a chance to share knowledge between the reviewer and the reviewer. And you can get down to all the subjective topics like does this code make sense? Is it clear? Those things a computer can't determine for you. Bonus round, scan your dependencies for vulnerabilities. Your libraries and applications contain dozens, if not more, direct and indirect dependencies. You need to make sure they don't contain vulnerabilities. Luckily there are a few great options around for that. I've been using the OWAS dependency check tool for years and it's been great. The only problem is there's a high rate of false positives. So these need to be managed with an excludes file. So you may end up with a few commits to your repository that are just managing this file. Next up there's dependent bot. So if anyone's using GitHub on a public repo you've probably already seen dependent bot. May have sent you pull request automatically. So that's another great choice. I've had some sort of mixed results with Maven multi-module projects in the past but I'm sure that's getting better. There are commercial options too. Sneak.io will scan your dependencies and even detect additional security issues that are not in the official NIST vulnerability database. That's it. I hope you can use these tools to help improve your code. If you liked this video, be sure to hit that like button and subscribe. You don't want to miss our future videos. Thanks for watching.