The Design and Implementation of laffer1

I've used Sonarqube for many years in various roles.  I've used the cloud version.  I've used the on-prem version.  I used to administer it at U-M on FreeBSD systems. 

There are a few issues that are getting increasingly annoying about it.  It's always had some bugs with respect to guessing the merge state on master.  However, it seems to have gotten worse in newer versions.  It can be way off in terms of coverage or duplicate detection. 

Then there are some of their newer "major" issues, like using guava's ImmutableMap.  There is NO REPLACEMENT in Java for this data type as is.  You can almost fake part of it with a combination of LinkedHashMap plus the immutable wrapper but it's still not there.   If you want to guarantee data will be in insertion order and also have access to of() style creation, there is nothing like it in base java.  So dinging people as though there's a compatible Java feature is insane, especially at major level.  It's info at best since it's something to check but likely not an issue!  Map.of doesn't work because it doesn't guarantee insertion order.  

Finally, there is should be a more reasonable UPPER limit on code coverage with the tool.  My employer's configuration requires 95% coverage for new PRs at this point.  That shouldn't even be a thing!  95% is crazy town.  You start writing bad code to avoid sonar dings.  Many teammates won't do null checks or write in a way that avoids null now.   This tool hurts quality when you push devs to that level of frustration.  

I think code coverage should be around 80-85% in Java. Anything more and you're just doing obnoxious things.