RFC: Which feature in SpotBugs core you're actively using?

[KengoTODA]

We're going to switch from developing 3.1 to 4.0 from the next month. And in this major version up, I want to consider to drop several features that isn't so used in community, to make our project easy to hack and maintain.

I will list features that is not so major in my personal understanding. Please vote for active feature in your usage. I will keep actively voted features even in 4.0.

Target Features

• scripts that is not used so widely.
• Bug rank that is optional and not so used widely in my understanding (each project has their priority, so it's better to handle 'rank' outside of SpotBugs like SonarQube)
• Priority/Confidence, by the same reason with bug rank
• 'speed' attribute in findbugs.xml
• SQL
• JNLP for outdated Java Web Start

Vote

[iloveeclipse]

Any clue how to vote?

[KengoTODA]

To vote, click bar in the post. Here is example: https://github.com/apex/gh-polls

[iloveeclipse]

And again, if you remove Bug Rank, Proirity and Confidence, you will not be able to use SpotBugs without SonarQube, so you will break Eclipse plugin and tools using xml output (so command line which generates html reports).

[KengoTODA]

Yes so we need to update Eclipse plugin side too. Let's do so if and only if these features are not used by users. :)

[iloveeclipse]

Sorry, I didn't get it. You propose to remove rank, confidence and priority - so how users are supposed to differentiate various bugs then? Another one metric?

[iloveeclipse]

Is there any reason why script and bug rank bars show 50% but confidence 100%, but all three have ea h one vote? Schouldn't the bars show same value?

[KengoTODA]

wmm, maybe it's problem caused by my process to make these polls. Only 'confidence and priority' is handled as individual polls so it's always 100%.

There are already multiple vote, so plz kindly let me keep current situation. I'll remember that bar chart of this item isn't intuitive.

[mkienenb]

Something to keep in mind.

If you are starting with a clean slate, you might not find rank important, but if you are applying spotbugs to an existing project for the first time, the output will be overwhelming. Rank gives people guidance which items need to be handled first.

Once everything is fixed, or if you are starting a new project, rank isn't as important.

[h3xstream]

I clicked on "priority and confidence". It was not clear if it was for the removal or for keeping the feature.

[KengoTODA]

@h3xstream keeping. please vote on feature that you are using. Sorry for this confusion :<

[KengoTODA]

@mkienenb yes I know, but most legacy projects don't need latest feature of SpotBugs, they just need 'bug fixed FindBugs' then 3.1.x should be enough. :)

[mkienenb]

@KengoTODA I think you misunderstood the point I was trying to make.

There will always be new end-users of spotbugs with existing unchecked projects. When they go and download the latest version of Spotbugs and run it for the first time, having the bug rank levels is going to be important. 'Bug-fixed findbugs' and 3.1.x may no longer be usable or available at that point, and even assuming that the version of java they are using permits it, should we be pointing first-time new end-users of spotbugs to another obsolete product or old versions?

Rank is always going to be useful for the "I just learned about static code analysis tools and want to start using them" category of end-users. They are not going to go download old versions of spotbugs nor will they download an abandoned project to try it out.

[ksnortum]

+1 Thank you for expressing this in a way I never could. The more a first time user gets alienated, the harder it is to expand the reach of the product.

…

-- Knute Snortum

On Fri, Feb 1, 2019, 5:25 AM Mike Kienenberger ***@***.*** wrote: @KengoTODA <https://github.com/KengoTODA> I think you misunderstood the point I was trying to make. There will always be new end-users of spotbugs with existing unchecked projects. When they go and download the latest version of Spotbugs and run it for the first time, having the bug rank levels is going to be important. 'Bug-fixed findbugs' and 3.1.x may no longer be usable or available at that point, and even assuming that the version of java they are using permits it, should we be pointing first-time new end-users of spotbugs to another obsolete product or old versions? Rank is always going to be useful for the "I just learned about static code analysis tools and want to start using them" category of end-users. They are not going to go download old versions of spotbugs nor will they download an abandoned project to try it out. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#65 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACI7wHFxmkagV_qW_ri9OSdfeql9D-Z_ks5vJEA7gaJpZM4aW0H4> .

[aaime]

I just added SpotBugs in the mix in a very old project, and single handedly started fixing issues. I started by fixing only rank 1, and bit by bit went up to rank 10 (mind, using build checks and having the build fail, without a build failure nobody else would have cared). Without a way organize reports by some sort of priority, I would not have been able to start (and indeed, I tried spotbugs first, was reporting too many things and could not figure out how to configure it, so I've integrated errorprone and pmd first, and only later added spotbugs to the mix too).

[KengoTODA]

Hello all,

Thanks for your feedback! Now I'm sure that some features are actively used. I'm little bit surprised that sql and jnlp also have users, but at least its usage isn't so high comparing than others:

I'm going to propose deprecating sql, jnlp and speed attribute. I won't touch others that has much users. :)