I don't normally use reflection directly while programming in Java. But I do use APIs and frameworks that internally rely on reflection or annotations to provide customization points.
A lot of frameworks use annotations to set up dependency injection or do some sort of automated logic wiring on your behalf.
This results in a lot of field, method, and constructor accesses which the static code analyzer can't follow, resulting in many false positives (not only "unused method/field" warnings). Is my only realistic option to continue to suppress these warnings, or are there other things I can do to help the analyzer better understand the real entry points of my classes?
I've heard some people discuss using test code for this purpose.
In a lot of the cases, I could probably write relevant test cases that make the warnings disappear, but I am worried about the rather large number of cases where that would involve testing implementation details instead of observable behavior. This code already has adequate branch coverage, and I don't want to write tests that I will regret writing every time I do maintenance. But if whitebox testing is really sometimes the "best" alternative, are there ways to help minimize the downsides? Fragility and implementation leakage are my primary concerns.