In part one of three, I covered the basics of making a quickfix pattern for a bug -
starting with parsing the Abstract Syntax Tree (AST) and ending with creating a new
ASTNode to replace the broken code.
In part two, this tutorial, we will be tackling a slightly more complicated bug that needs resolving:
Randoms are not super secure.
In cases where they need to be less guessable, it is better to either use a SecureRandom (at the cost of speed), or simply initialize a Random with a long from SecureRandom (mitigates time-based attacks and faster, but still not super secure).
The user will have to decide which one of the two suggested fixes applies, so we need to give them a choice. This tutorial will show how to offer two quickfixes as well as customizing the descriptions to give more information.
One Weird Random QuickFix Recipe (that will totally be clickbait)
- Preparation time
- Coding time
- Hopefully getting the hang of this
- A light airy second course, before the rich desert
If you've already done the first part, you should have an Eclipse project
Otherwise, download this preconfigured Eclipse workspace and then install the dev version of FindBugs from
If you want to do this in hard mode, follow the dev setup instructions for fb-contrib quickfixes - it will amount to basically the same thing.
Registering two quickfixes for the BugPattern MDM_RANDOM_SEED
Just like last time, we'll start by modifying the plugin.xml file. The main difference you will notice is that we register two fixes for the same resolution. This will make both fix options pop up on the list of resolutions.
Making the two fixes
To make two separate fixes, we'll need to override
setOptions() to distinguish between them and then code in the separate fixes.
TypeBindings for the visitor implementation below. This method handles the parsing of any arguments you pass in. The arguments will be parsed as comma-separated, if you need more than one. And we simply use the parsed argument from above to determine the fix to apply. This call is from the FindBugs plugin.eclipse.quickfix.util.ASTUtil class and will add, if it doesn't already exist, a reference to SecureRandom. This is a simple way to create a constructor invocation of SecureRandom. One downside is that it won't deal with imports, potentially leaving a compilation error. Line 31 corrects this oversight. Makes a call to
new Random()Chains a newly created SecureRandom to a call of nextLong:
nextLong()Takes the output of the long generated from the
SecureRandomand uses that to initialize the
Randomobject we made in 42-44.
The only tricky part to this so far is the creation of the new ASTNodes. Remember that ClassInstanceCreations are when a constructor is called (i.e. a class instance is made). Do not be tempted by the (more logically named) ConstructorInvocation.
Making the visitor
This visitor is very straight forward because we only have to look for when a Random is created.
Showing Custom Descriptions
The last piece is supplying custom descriptions, which simply involves overriding the aptly named getDescriptions method.
ConclusionThis example showed a slightly more involved quickfix, with two options. Next time, for the last of the three parts, we'll go all out, looking at an example with custom labels and complex type logic.